When restoring gradle build and configuration cache on github actions we get

Calculating task graph as configuration cache cannot be reused because the set of Gradle properties has changed.

How can I find out which properties (that affect configuration cache) are changed? There should be no changes, as this pops up even on builds on the same commit?

I guess a build scan can tell you

https://docs.gradle.org/nightly/userguide/configuration_cache.html#config_cache:not_yet_implemented:fine_grained_tracking_of_gradle_properties TL;DR Currently, all external sources of Gradle properties (gradle.properties in project directories and in the GRADLE_USER_HOME, environment variables and system properties that set properties, and properties specified with command-line flags) are considered build configuration inputs regardless of what properties are actually used at configuration time.

@Vampire a build scan does not tell us what changed in order to trigger config cache to be considered invalid. @Paul Merlin Is there a way to get those printed out? The

gradle.properties

and environment variables I can check, as well as command-line flags, but is there a way to print out all properties other than those, that might affect configuration cache? The output of

./gradlew properties

between runs differs in some hashes, could that be the cause? If so, what could be the reason for that, since gradle user home is saved and restored, as well as

<project>/.gradle/configuration-cache

?

Then store the configuration cache report in

build/reports

as artifact, there all inputs should be listed. Then you should be able to compare it or see which might change.

I already do, I get no useful information from that. As far as I understand, that is a report of storing the configuration cache, not using it. Also, from the docs:

These sources, however, are not included in the configuration cache report.

As far as I understand, that is a report of storing the configuration cache, not using it.

That's right, but if it does not reuse it for some reason and then stores another one, you should be able to compare the old one with the new one and see a difference. If there is no difference, it is probably in those mentioned cases that are not added to the report. So I guess indeed

The output of

./gradlew properties

between runs differs in some hashes, could that be the cause

is the cause if they come from one of the non-reported locations. But probably hard to guess without telling which hashes you mean.

property values aren't shown in reports on purpose

So, these are outputs from two runs from

./gradlew properties

-> if you do a compare you’ll see the differences. They are for instance the

@hash

for these two lines:

ant: org.gradle.api.internal.project.DefaultAntBuilder@7ffd3d78
antBuilderFactory: org.gradle.api.internal.project.DefaultAntBuilderFactory@6c95d08f

I’ve checked, some environment variables also change on CI runs (github actions sets the run id, commit hash, etc. into env), but they aren’t mentioned in the config cache report.

Ok, those aren't part of what the configuration cache looks at. The

:properties

task uses

Project.getProperties()

which include way too much things.

The question is whether it should contain the "problematic" things.

Yeah, I thought so too, that’s why I’ve been asking if there’s a way to print out the properties config cache is sensitive to, to figure out what is changing 🙂

Besides the memory addresses of those objects the properties in those files are identical

Here's a task that uses internals to print only what CC considers:

abstract class ReportLoadedGradleProperties : DefaultTask() {
    @TaskAction
    fun action() {
        println(
            services.get(org.gradle.initialization.GradlePropertiesController::class.java)
                .gradleProperties
                .mergeProperties(emptyMap())
                .entries
                .joinToString("\n")
        )
    }
}

tasks.register<ReportLoadedGradleProperties>("reportLoadedGradleProperties")

Excellent, thank you for your help. I think I’ve found the culprit: one of the properties is the

secrets.GITHUB_TOKEN

, which we need to authenticate to our internal maven repository. I guess there’s no way around not triggering CC since this is automatically generated by github for each run separately? Edit: to be clear, we set it with

-PmavenPassword

and retrieve with

credentials(PasswordCredentials::class)

You could probably create a fixed token that you supply instead of using the auto-generated one.

Yeah, we might add a static user+password, now that I know what the issue is, although I doubt it, as there’ different permissions for different users. In any case, with this knowledge I can take appropriate actions. CC is not that relevant on CI, that’s true, but for some builds it takes longer to configure than to execute the build/test as it’s a big multi module project. Thank you both for all your help getting to the bottom of this 👍