Skip to content
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

Open
grandstaish opened this issue Dec 2, 2021 · 13 comments
Open

Comments

@grandstaish
Copy link

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
Copy link
Owner

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
Copy link
Author

grandstaish commented Dec 2, 2021

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

@runningcode
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link

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

Found some offending lines here:

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

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
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor

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
Copy link

asavill commented Dec 11, 2022

@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
Copy link
Contributor

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?

Screenshot 2023-05-30 at 11 22 29

@runningcode
Copy link
Owner

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
Copy link
Contributor

kozaxinan commented May 30, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants