Find out what caused my configuration cache to invalidate

Help/Discuss
1

Is there a way to list the value sources or properties or whatever that caused the configuration cache to become invalid? Just a string representation of each thing that invalidated that cache would be great.

I’d like to add this to my usual output. If I run a gradle task but gradle determines that the cache is invalid, configuration will occurs. Whenever configuration occurs because of the cache being invalid, I’d like to see something like the following in my console:

configuration cache was invalid because of the following:
    - ValueSource x changed
    - property y changed
2

That’s exactly what happens already.
I tested with this little snippet:

abstract class TestValueSource : ValueSource<String, ValueSourceParameters.None> {
    override fun obtain(): String {
        return kotlin.random.Random.nextInt().toString()
    }
}
println(providers.of(TestValueSource::class) {}.get())

and executed the help task twice with configuration cache enabled and the output says:

Calculating task graph as configuration cache cannot be reused because a build logic input of type ‘TestValueSource’ has changed.

3

Ah, gotcha! I must have done something to disable this a long time ago and forgot. I will look into it. Thanks again @Vampire !

4

Actually, I’m not aware that you even could disable it.
Maybe you expect it at the end of the output, but it is printed in the beginning of the build where it is determined that the CC cannot be reused.

5

It was my log level :man_facepalming:

6

I would like to keep my org.gradle.logging.level=warn but still be able to somehow have access to this information, ideally programatically. If it can’t be programatic, at least if I can selectively include it in my console when my log level is warn without including the other things. I am finding that it doesn’t show in lifecycle either. It requires info.

7

Its difficult to find where/how this is printed because there are so many tests using the same exact string. See my GitHub search here.

8

I’ve tried using advanced GitHub search syntax as you can see here, but I still cannot find where in the source code this information is logged.

9

and

and

For me it is printed on lifecycle level, but I guess you combine the org.gradle.logging.level=warn with --quiet or something like that.

You cannot really influence on a single message level which things are logged and which are not, unless you replace the logging of Gradle with your own implementation as documented at Logging

1 Like
10

That makes perfect sense. Maybe I’ll try to invent a hack of some sort, or maybe I’ll just temporarily enable lifecycle logging or disable quiet temporarily when I need this information. Thanks!

1 Like