configureFulladle task is not compatible with configuration caching

[grandstaish]

We just enabled configuration caching in our project, but had to disable it for our tests because of the following error:

1 problem was found storing the configuration cache.
- Task `:configureFulladle` of type `org.gradle.api.DefaultTask`: cannot serialize object of type 'org.gradle.api.internal.project.DefaultProject', a subtype of 'org.gradle.api.Project', as these are not supported with the configuration cache.
  See https://docs.gradle.org/7.3/userguide/configuration_cache.html#config_cache:requirements:disallowed_types

[runningcode]

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.

[grandstaish]

Ah so fulladle isn't intended to be compatible yet?

[runningcode]

What would be the benefit? I imagine that most use cases of configureFulladle are run on a CI environment where configuration cache is disabled. Am I missing something.

[PhilGlass]

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!

[runningcode]

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.

[ZakTaccardi]

Configuration cache support is very important, not just for itself but for the upcoming Project Isolation feature.

Found some offending lines here:

https://github.com/runningcode/fladle/blob/56e28a3bc4468867f57a84cb917c56a0382f8705/fladle-plugin/src/main/java/com/osacky/flank/gradle/FulladlePlugin.kt#L20 https://github.com/runningcode/fladle/blob/56e28a3bc4468867f57a84cb917c56a0382f8705/fladle-plugin/src/main/java/com/osacky/flank/gradle/FulladlePlugin.kt#L39

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

[CristianGM]

Just to clarify: At Ephemeral CI the configuration-cache can be used, is just caching a folder, it doesn't need to be relocatable because the path is always the same.

I enabled CC at some projects for both local and CI builds and it works perfectly.

[runningcode]

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.

At this stage, we do not recommend that you change your plugin to be somehow "project isolation compatible", as there is no stable definition of what this means yet, nor are all the necessary APIs in place to allow this.

@CristianGM can you confirm that configuration caching without project isolation enabled is working for you and we can close this ticket?

[CristianGM]

I never used fulladle.

I just said CC works at CI because in a previous comment you assumed the opposite:

I imagine that most use cases of configureFulladle are run on a CI environment where configuration cache is disabled.

[asavill]

@runningcode FWIW, fladle isn't configuration cache compatible, even without project isolation because it uses project directly in it's tasks. Not sure if it would be possible to change this but there's a table of suggestions in the cache documentation.

https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:troubleshooting

[kozaxinan]

We also need to call runFlank locally to verify the new tests. At the moment, we suggested team to add --no-configuration-cache flag when they call runFlank but that is error prone.

Is there a way to configure gradle so it doesnt use cc at all for fulladle related tasks?

[runningcode]

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

[kozaxinan]

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.

* What went wrong:
Execution failed for task
':configureFulladle'
> Cannot invoke
"org.gradle. api. Project. subprojects (o rg.gradle. api. Action) " because "this. this$0. $root" is null