-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
configureFulladle task is not compatible with configuration caching #285
Comments
Thanks for reporting. As it stands fulladle needs to scan all projects in the task action order to find out which modules to add. I will look in to seeing if there is another possibility. |
Ah so fulladle isn't intended to be compatible yet? |
What would be the benefit? I imagine that most use cases of |
Agreed that there's little benefit right now, but when the configuration cache is relocatable and/or supports intra-module parallel task execution on the first run there will be! |
Thanks, I just wanted to clarify in order to correctly prioritize this. I will keep this low priority as long as the configuration cache is not relocateable. Of course, PRs are always welcome. |
Configuration cache support is very important, not just for itself but for the upcoming Project Isolation feature. Found some offending lines here:
Configuration needs to bubble up from the subprojects first. Then a final, aggregation plugin (which would be Fulladle) observes output of those subprojects. However, project isolation could be supported today by designing fulladle to behave like this: // in a standalone subproject (not the root) like `:fulladle`
plugins {
id("fulladle-with-project-isolation-support")
}
dependencies {
// manually list each dependency that should be included in fulladle
add("fulladle", ":lib-a")
add("fulladle", ":lib-b")
add("fulladle", ":lib-c")
} The problem here is that Gradle currently lacks APIs to conditionally depend on subprojects (see here) at the moment. So you still need to loop over subprojects to identify which ones to add. And on how to correctly share outputs between projects, check out https://docs.gradle.org/current/userguide/cross_project_publications.html |
Just to clarify: I enabled CC at some projects for both local and CI builds and it works perfectly. |
To clarify: this ticket is about configuration caching. We will not yet look in to project isolation until Gradle has implemented all the necessary APIs to make this possible.
@CristianGM can you confirm that configuration caching without project isolation enabled is working for you and we can close this ticket? |
I never used fulladle. I just said CC works at CI because in a previous comment you assumed the opposite:
|
@runningcode FWIW, fladle isn't configuration cache compatible, even without project isolation because it uses https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:troubleshooting |
Yes, you can declare a task not compatible with configuration cache: https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:task_opt_out |
Task.notCompatibleWithConfigurationCache() doesn't prevent issue. Because querying subproject doesn't work when configuration cache is enabled even if task is not compatible. I get the following error after configuration cache warnings.
|
We just enabled configuration caching in our project, but had to disable it for our tests because of the following error:
The text was updated successfully, but these errors were encountered: