Build cache key consistent, but build cache always misses

Help/Discuss
1

I have a custom task class, implemented in Groovy. It is a @CacheableTask with several @Input properties plus one @OutputFile property. Both --scan and -Dorg.gradle.caching.debug=true show that the build cache for a given task instance remains consistent: it does not change each time I rebuild. In spite of this, the build cache never hits.

For example, one build scan shows:

Build cache result Miss (local), Store (local)
Cache key 8dde787e4212662d5cefe1cd040b401d
Cache artifact 39.58 kB / 2 entries
Pack 0.021s

After manually removing the output file and running a second build, the second build’s scan shows:

Build cache result Miss (local), Store (local)
Cache key 8dde787e4212662d5cefe1cd040b401d
Cache artifact 39.58 kB / 2 entries
Pack 0.026s

Notice that the cache key has not changed. In spite of this, the “Store (local)” from the first build was followed by a “Miss (local)” in the second build. Why did the second build miss given that the first build stored the artifact and the key remained the same?

I can see the gzip’d tar archive stored in ~/.gradle/caches/build-cache-1/8dde787e4212662d5cefe1cd040b401d. But if I remove the task’s output file and rebuild, Gradle always performs the task’s work anew, rather than using the copy stored in the build cache. Gradle even replaces this stored copy with the newly-rebuilt task output.

All documentation I can find on debugging the build cache focuses on figuring out why the build cache key is changing. My build cache key is not changing. How do I diagnose build cache misses when the problem is not due to unwanted build key changes?

2

Hi Ben,

if you look at the reason why the task executed in the build scan, you see that it says:

The task was not up-to-date because Task.upToDateWhen was false.

That means that you are using upToDateWhen { <something that evaluates to false> }. When upToDateWhen evaluates to false, that implies that Gradle does not try to load from the cache and the task is always re-run.

Cheers,
Stefan