When restoring gradle build and configuration cach...
# configuration-cache
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
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
Then store the configuration cache report in
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
@Gasper Kojek could you please clarify what are those hashes you mention?
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
for these two lines:
Copy code
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
task uses
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:
Copy code
abstract class ReportLoadedGradleProperties : DefaultTask() {
    fun action() {

❤️ 2
Excellent, thank you for your help. I think I’ve found the culprit: one of the properties is the
, 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
and retrieve with
Copy code
You could probably create a fixed token that you supply instead of using the auto-generated one.
Or you just don't care about configuration cache on CI where it shouldn't be that relevant 🙂
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 👍