Hello together, our Gradle project looks like the following:

topLevel
 includeBuild("app")
 includeBuild("library")

topLevel/app
 includeBuild("../library")

topLevel/library

In words, the top-level project includes "the app" and "the library" via composite builds and "the app" includes "the library" via composite builds. By default we have open the "topLevel" project so that we can make changes in the library as well as in the app in our IDE. library as well as app are multi-module android projects. Now we wanted to take a look at the configuration cache. We enabled the cache for all three projects. If I run

assembleDebug

on the library project everything works as expected. I don't get any issues. If I run

assemble[BuildFlavor]Debug

within "the app" project, I also don't get any configuration cache issues. Gradle tells me that the cache was stored and found 0 issues. If I run it the second time (so the configuration cache will be restored) I get a (build?) error with the message:

> Error while evaluating property 'filteredArgumentsMap' of task ':library:lib😮ptional:kaptGenerateStubsDebugKotlin'.

> GradleProperties has not been loaded yet.

I get this even for several sub-projects of the library. Not only for one, but also not for all. The stacktrace doesn't help me either. I use Gradle 7.6, Kotlin 1.7.21 and the AGP 7.4.0 I (may) found related issues: https://youtrack.jetbrains.com/issue/KT-56478 https://youtrack.jetbrains.com/issue/KT-48756 https://github.com/gradle/gradle/issues/13122 But none of them helped me. And I'm also not sure if this is an kapt issue or rather an Gradle issue. A reason why I also want to raise this here. Is this an known issue in Gradle? Can I workaround this somehow? Or can anybody help me here? Thanks in advance and happy Friday and weekend to all 🙂

How does the configuration cache treats

@Internal

task fields? I'm guessing it's OK to have

@Internal

fields as long as they are

Serializable

? But anything else will probably fail, right?

If the plugin defines a task can I write a custom configuration cache aware task that calls a task from the plugin?

According to the public roadmap, configuration caching is going to be stabilized in Gradle 8.1. Will it also be enabled by default at that time?

is there a way to get a stacktrace or something of configuration cache failures? I'm trying to diagnose a problem but I just can't connect the HTML report to my code, I can't see any match

What about configuration cache support in/with the kotlin plugin? It is not listed at https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:plugins

A test I have to check project isolation is failing due accessing a project property in the root project after upgrading to Gradle 8

32 problems were found storing the configuration cache, 2 of which seem unique.
  - Plugin 'com.javiersc.semver.gradle.plugin': Project ':library-a' cannot dynamically look up a property in the parent project ':'
  - Plugin 'com.javiersc.semver.gradle.plugin': Project ':library-b' cannot dynamically look up a property in the parent project ':'

I am accessing using the typical

properties["..."]

, so Gradle knows that the properties are in the root

gradle.properties

. This is a new limitation with Gradle 8 and I should move those properties to each project? It can be annoying as it is a property that can be shared on all projects.

I have a problem with reusing the configuration cache on our CI. When running builds one after another, a message is logged:

Calculating task graph as configuration cache cannot be reused because the set of environment variables prefixed by 'ORG_GRADLE_PROJECT_' has changed.

- GradleEnterprise scan diff shows no difference between builds -

build/reports/configuration-cache

report the same values, just some variables have different positions in the file. How can I find the cause of this cache miss? (Gradle version 8)

I have a question regarding parallelism and the configuration cache. I have a project (

micronaut-test-resources

) which does not use parallel builds, because of some tests which are resource intensive.

Hi! I’m trying to reuse configuration cache in Gitlab CI, and though I’ve succeed to get to

Reusing configuration cache.

message but the build fails with

ClassNotFoundException

(stacktrace in thread). Locally everything works perfectly. Is managing

.gradle/configuration-cache

persistence and providing reproducible environment not sufficient to enable CC on CI, or am I missing something?

Hello, fellow configuration cache early users. I'm trying to understand if the javadocs are outdated, or if I'm missing something regarding dependency graphs as inputs.

While we are at making things compatible with the configuration cache, there is some code in the GraalVM native plugin which does this:

Hi, it's me again! In https://github.com/micronaut-projects/micronaut-gradle-plugin/blob/ffde7db1c93a1ec2bafb37a8861d0d29e9c3b9f1/buildSrc/src/main/groovy/io.micronaut.internal.build.testing.gradle#L34-L61, I am scanning the source directories to create separate test tasks for each package.

Should https://github.com/gradle/gradle/issues/24390 maybe be added to stable CC project? After all it's the transformer for CC causing this problem.

Hi, We are using gradle 7.6 and have finally implemented gradle configuration cache. However we get some very weird behaviour with the

application

plugin. We have specified the following configuration.

applicationDefaultJvmArgs = listOf(
        "--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED",
        "--add-exports=java.base/sun.nio.ch=ALL-UNNAMED",
        "--add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED",
        "--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED",
        "--add-opens=jdk.compiler/com.sun.tools.javac=ALL-UNNAMED",
        "--add-opens=java.base/java.lang=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.reflect=ALL-UNNAMED",
        "--add-opens=java.base/java.io=ALL-UNNAMED",
        "--add-opens=java.base/java.util=ALL-UNNAMED")

It seems that if the configuration cache is used those JVM args do not get passed to the process. If we run gradle with

--no-configuration-cache

then everything works as expected. Anybody have any ideas? We are running the gradle

run

task.

I have an init script that configures a version catalog in the same fashion as https://github.com/gradle/gradle/blob/b9d0cd50ede118abc09ccb3a43c452a8e22a33f5/sub[…]rg/gradle/configuration/BuildTreePreparingProjectsPreparer.java My code was modelled after the 7.4.2 release code and does not contain the

Instrumented.fileObserved

call for the config cache. Is this something I'll need to port into my init script once I upgrade and start using the CC? Is there a more public API way of doing what's necessary?

Is accessing task graph (via

gradle.taskGraph.whenReady { .. }

) and operations on it configuration cache compatible? Will I just receive cached graph?

Are there plans to make the configuration cache able to be stored remotely in Gradle Enterprise?

Issue related to encryption after upgrading to 8.1 🧵

I’m trying to figure out the cause of a configuration cache failure, but I’m stuck. The error message that Gradle gives isn’t useful, and doesn’t seem correct. Could someone help please?

Task `:subproject-hello:dokkatooGenerateModuleHtml` of type `dev.adamko.dokkatoo.tasks.DokkatooGenerateTask`: cannot serialize Gradle script object references as these are not supported with the configuration cache.

I’m using

.kt

files to write the plugin, not

.kts

files, so I don’t know why the error is saying there’s a problem with a Gradle scripts? Reproducer in 🧵

I’m trying to wrap my head around

OperationCompletionListener

and

FlowAction

. These are both config-cache compatible mechanisms for receiving events, the former for task-finished events and the latter for build-finished events. Is there a reason they are completely seperate APIs? Are there plans to merge them?

I migrated our custom jdk resolution to make use of gradle toolchain support. unfortunately now I deal with that cc issue:

* What went wrong:
Configuration cache problems found in this build.

1 problem was found storing the configuration cache.
- Plugin 'elasticsearch.global-build-info': external process started 'sysctl -n hw.physicalcpu'
  See <https://docs.gradle.org/8.1/userguide/configuration_cache.html#config_cache:requirements:external_processes>

The related userguide didn't help much. Is that a known issue? is there a workaround/fix for this?

Can accessing

project

in

Task.onlyIf

cause

invocation of 'Task.project' at execution time is unsupported.

when config cache is enabled? I started getting this error after updating to Gradle 8.1 and the only thing in the task that's referencing

project

is in the

onlyIf

https://github.com/Triple-T/gradle-play-publisher/issues/1083 https://github.com/Triple-T/gradle-play-publisher/blob/master/play/plugin/src/main/kotlin/com/github/triplet/gradle/play/tasks/CommitEdit.kt#L21

Is there a configuration cache-compatible way to set

standardInput

of

org.gradle.api.tasks.JavaExec

to

<http://System.in|System.in>

? I got this error:

FAILURE: Build failed with an exception.

* What went wrong:
Maximum number of configuration cache problems has been reached.
This behavior can be adjusted, see <https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:usage:max_problems>.

1 problem was found storing the configuration cache.
- Task `:my:task` of type `org.gradle.api.tasks.JavaExec`: cannot serialize object of type 'java.io.PipedInputStream', a subtype of 'java.io.InputStream', as these are not supported with the configuration cache.
  See <https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:disallowed_types>

The context is I have a

JavaExec

task that requires user input from the command line at runtime

tasks.processResources {
    filesMatching("**/version.txt") {
        filter { line: String ->
            getTemplatedString(line)
        }
    }
}
fun getTemplatedString(input: String) : String {
    .......
    .......
    .......
    return "something"
}

I am trying to build convention plugin with this logic. When I enable configuration cache, I get this error - 1 problem was found storing the configuration cache. - Task

:processResources

of type `org.gradle.language.jvm.tasks.ProcessResources`: cannot serialize Gradle script object references as these are not supported with the configuration cache. How do I make this compatible with configuration cache?

hi! I had an issue on a CI machine running a build with configuration cache on (I just enabled it before making changes locally to make sure no issues would arise)

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache problems found in this build.

2 problems were found storing the configuration cache, 1 of which seems unique.
- Task `:redacted:generateReleaseProto` of type `com.google.protobuf.gradle.GenerateProtoTask`: invocation of 'Task.project' at execution time is unsupported.
  See <https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution>

See the complete report at file:///redacted/build/reports/configuration-cache/3mf8hghvfa02wwvtjlwqc59gg/cy6abpuc9o24o4cjazezyewuu/configuration-cache-report.html
> Invocation of 'Task.project' by task ':redacted:generateReleaseProto' at execution time is unsupported.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

I do not get that error locally on my machine. What could be different between my settings and the CI machine’s one? How can I diagnose such errors?

Hi! Do you know what is the meaning of

cannot serialize Gradle script object references as these are not supported with the configuration cache.

as an error in configuration cache storage?

Is it possible to call the getDidWork function of another task in a way that supports configuration cache? Storing a copy of a task in a property makes gradle pretty angry.

Is it possible to dynamically register a new task when another task is added (or configured?) Like in our case we’d like to register a “do after” task for each JacocoReport task. The code

pProject.getTasks().withType(JacocoReport.class, reportTask -> {

eager evaluates each jacocoreport (I believe?) but I’m not sure how to dynamically add a task without configuring the former. whenTaskAdded didn’t seem to work, and configureEach doesn’t let you register a task (perhaps it runs too late?)

I'm trying to make things configuration-cache friendly, but I can't figure out how to access the task graph (

TaskExecutionGraph

). I want to call

taskGraph.hasTask("...")

in the

@TaskAction

of a

Task

. I tried injecting

Gradle

,

TaskExecutionGraph

, all kinds of

project.provider

and even

ValueSource

, but no luck yet. What's the right way?