configureFulladle task is not compatible with configuration caching

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

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 configureFulladle are run on a CI environment where configuration cache is disabled. Am I missing something.

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:

fladle/fladle-plugin/src/main/java/com/osacky/flank/gradle/FulladlePlugin.kt

Line 20 in 56e28a3

extensions.create("fulladleModuleConfig", FulladleModuleExtension::class.java)

fladle/fladle-plugin/src/main/java/com/osacky/flank/gradle/FulladlePlugin.kt

Line 39 in 56e28a3

root.subprojects {

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:
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.

@CristianGM

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?

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.

@runningcode

@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

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?

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.

* 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

Fix configuration cache compatibility for configureFulladle task (#285)

Is it still the problem? I think we have configuration cache enabled and Fulladle is not reported. I will check tomorrow.

Navigation Menu

Repository navigation

configureFulladle task is not compatible with configuration caching #285

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

configureFulladle task is not compatible with configuration caching #285

Description

Activity

runningcode commented on Dec 2, 2021

grandstaish commented on Dec 2, 2021

runningcode commented on Feb 1, 2022

PhilGlass commented on Feb 2, 2022

runningcode commented on Feb 2, 2022

ZakTaccardi commented on Feb 3, 2022

CristianGM commented on May 3, 2022

runningcode commented on May 4, 2022

CristianGM commented on May 4, 2022

asavill commented on Dec 11, 2022

kozaxinan commented on May 30, 2023

runningcode commented on May 30, 2023

kozaxinan commented on May 30, 2023

emartynov commented on Mar 16, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions