Included builds containing build logic prevent configuration-cache reuse

[scana]

Hi!

Just tried out Gradle 8.6 with gradle/actions/setup-gradle@v3 and it seems like a build-conventions (https://docs.gradle.org/current/samples/sample_sharing_convention_plugins_with_build_logic.html) related task input change is preventing my configuration-cache from being reused.
They do seem to cache fine on local builds.

Calculating task graph as configuration cache cannot be reused because 
an input to task ':build-conventions:generatePluginAdapters' has changed.

Sample job that I run:

- name: Run ktlint
  uses: gradle/actions/setup-gradle@v3
  with:
    gradle-home-cache-cleanup: true
    cache-encryption-key: ${{ secrets.GRADLE_CACHE_ENCRYPTION_KEY }}
    arguments: ktlintCheck

Is there any chance this might be related to gradle-home-cache-cleanup #19 ?
If not, is there anything else that we should cache?

I suppose build conventions falls under this category:

caches/<version>/kotlin-dsl and caches/<version>/scripts: These are the compiled build scripts. The Kotlin ones in particular can benefit from caching.

[bigdaz]

Thanks for the report. The configuration-cache hasn't been designed to be reused on different machines, but with gradle-build-action and the Gradle User Home fully restored we've found that it often works. Unfortunately you seem to have found a case where it doesn't.

The error message indicates that GRADLE_ENCRYPTION_KEY is being set correctly and the configuration-cache is being properly restored. But something in the project state isn't as expected after restore, invalidating the cache entry.

I suspect that this is due to the following process:

• When your project is configured, you have an included build build-conventions that must be built in order to provide some build logic.
• This results in the inputs to task :build-convention:generatePluginAdapters being marked as configuration-cache inputs.
  • The generatePluginAdapters task likely has some inputs that are actually the outputs of other build-conventions tasks, and are located in the build-conventions/build directory.
• When your workflow runs, the gradle-build-action will restore the Gradle User Home together with the configuration-cache entry. But it will not restore the build-conventions/build directory. This results in the "configuration cache cannot be reused" message you see.

You could validate this locally by:

1. Run the build locally, storing the configuration-cache entry
2. Clean the local build, including any included-builds. This might require manual deletion of the build directories.
3. Run the build again and see if the configuration-cache can be reused.

[scana]

Thank you for clarifying this @bigdaz.
I did play with cleaning up parts of the project in order to further investigate this.
Perhaps there's a smarter way to do it but I did try removing directories one by one.

Removing build-conventions/build results in:

Calculating task graph as configuration cache cannot be reused because 
an input to plugin 'org.gradle.groovy-gradle-plugin' has changed.

Just build-conventions/build/pluginDescriptors:

Calculating task graph as configuration cache cannot be reused because 
an input to task ':build-conventions:processResources' has changed.

build-conventions/build/resources:

Calculating task graph as configuration cache cannot be reused because 
an input to task ':build-conventions:jar' has changed.

build-conventions/build/classes:

Calculating task graph as configuration cache cannot be reused because 
an input to task ':build-conventions:compileGroovyPlugins' has changed.

And finally build-conventions/build/groovy-dsl-plugins/output/plugin-requests gives me the message that I'm seeing on CI:

Calculating task graph as configuration cache cannot be reused because 
an input to task ':build-conventions:generatePluginAdapters' has changed.

Is this something could perhaps be cached on the side? Not sure if setup-gradle action takes care of local build files other than those located in Gradle home dir?

[bigdaz]

The setup-gradle task doesn't (currently) take care of any of this, so you'll need to configure this yourself. The simplest way is probably using actions/cache to save/restore the build-conventions/build directory.

If you get this working, please share the configuration for others.

[scana]

Didn't get this to fully work yet, but thought it might be worth sharing what I've tried already.

- name: Cache build logic
  uses: actions/cache@v4
  with:
    path: build-conventions/build/groovy-dsl-plugins/output/plugin-requests
    key: build-logic-${{ hashFiles('build-conventions/**/*.gradle', 'gradle/libs.versions.toml') }}

Results in:

Calculating task graph as configuration cache cannot be reused because an input to task ':build-conventions:compileJava' has changed.

Changing path to build-conventions/build/ either successfully reuses the configuration or fails with:

Calculating task graph as configuration cache cannot be reused because an input to plugin 'org.gradle.groovy-gradle-plugin' has changed.

---

I have also encountered an error right now when trying to run a build, but I suppose this could be a separate issue?

* What went wrong:
Could not load the value of field `parameters` of `org.gradle.api.internal.provider.DefaultValueSourceProviderFactory$DefaultObtainedValue` bean found in field `obtainedValue` of `org.gradle.configurationcache.fingerprint.ConfigurationCacheFingerprint$ValueSource` bean found in Gradle runtime.
> com.android.build.gradle.internal.services.AndroidLocationsBuildService$AndroidDirectoryCreator$Params

Additional references:

• Configuration Cache: ClassNotFoundException: KotlinCompile  gradle#25864 (comment)
• https://issuetracker.google.com/issues/311414908

[bigdaz]

The best way to solve this is likely to experiment locally. Something like:

./gradlew help
rm -rf build-conventions/build
./gradlew help

The second build should reproduce the configuration cache issue you're seeing on CI. You can then experiment to see exactly what needs to be restored. I suspect the entire build-conventions/build directory will be required.

Also, the cache key should probably include all source files under build-conventions. Any change to these sources could change the outputs in build, and these are required to reuse the configuration cache.

[bigdaz]

Another option to solve this would be to add a separate ./gradlew :build-conventions:assemble --no-configuration-cache step prior to your main build step. This should ensure that all included build logic is available when reusing the configuration cache.

[hfhbd]

I have a small pet project that never reuses the CC, so I added the build logic directory manually: https://github.com/hfhbd/adventOfCode/pull/29/files and it does work now! So it would be nice, if this action would store the this directory (or at least the relevant parts) by default.