I have a custom task class, implemented in Groovy. It is a
@CacheableTask with several
@Input properties plus one
@OutputFile property. Both
-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?