Build Cache keys: how do I suppress (filter out) unwanted input properties?

Help/Discuss
1

Using the gradle build cache, how do I prevent the build key using unnecessary inputs:

eg. none of the following inputs are relevant to the cached build output:

Appending inputPropertyHash for 'reports' to build cache key: 789ba6a82cd7b7e226785c5a85a120d4
Appending inputPropertyHash for 'reports.enabledReports.html' to build cache key: 366534feb771f9d20bb9e1f9d60c90f9
Appending inputPropertyHash for 'reports.enabledReports.html.displayName' to build cache key: 65516431e282472fd65e52bc5dcf1dd6
Appending inputPropertyHash for 'reports.enabledReports.html.enabled' to build cache key: f6d7ed39fe24031e22d54f3fe65b901c
Appending inputPropertyHash for 'reports.enabledReports.html.name' to build cache key: 45b63c04ebea9f3558fe60946eb8d98b
Appending inputPropertyHash for 'reports.enabledReports.html.outputType' to build cache key: 0c5a7f9ee0b1630048617c6a027bb3ce
Appending inputPropertyHash for 'reports.enabledReports.junitXml' to build cache key: d0e3ff4c15a23a80b60087a90f1fe7a8
Appending inputPropertyHash for 'reports.enabledReports.junitXml.displayName' to build cache key: 590d7582741dbef11d71eeba4e65d1cc
Appending inputPropertyHash for 'reports.enabledReports.junitXml.enabled' to build cache key: f6d7ed39fe24031e22d54f3fe65b901c
Appending inputPropertyHash for 'reports.enabledReports.junitXml.name' to build cache key: 1fca07d69580ccd153cbc5aff057ccf5
Appending inputPropertyHash for 'reports.enabledReports.junitXml.outputPerTestCase' to build cache key: c06857e9ea338f3f3a24bb78f8fbdf6f
Appending inputPropertyHash for 'reports.enabledReports.junitXml.outputType' to build cache key: 0c5a7f9ee0b1630048617c6a027bb3ce
Appending inputPropertyHash for 'reports.html' to build cache key: 366534feb771f9d20bb9e1f9d60c90f9
Appending inputPropertyHash for 'reports.html.displayName' to build cache key: 65516431e282472fd65e52bc5dcf1dd6
Appending inputPropertyHash for 'reports.html.enabled' to build cache key: f6d7ed39fe24031e22d54f3fe65b901c
Appending inputPropertyHash for 'reports.html.name' to build cache key: 45b63c04ebea9f3558fe60946eb8d98b
Appending inputPropertyHash for 'reports.html.outputType' to build cache key: 0c5a7f9ee0b1630048617c6a027bb3ce
Appending inputPropertyHash for 'reports.junitXml' to build cache key: d0e3ff4c15a23a80b60087a90f1fe7a8
Appending inputPropertyHash for 'reports.junitXml.displayName' to build cache key: 590d7582741dbef11d71eeba4e65d1cc
Appending inputPropertyHash for 'reports.junitXml.enabled' to build cache key: f6d7ed39fe24031e22d54f3fe65b901c
Appending inputPropertyHash for 'reports.junitXml.name' to build cache key: 1fca07d69580ccd153cbc5aff057ccf5
Appending inputPropertyHash for 'reports.junitXml.outputPerTestCase' to build cache key: c06857e9ea338f3f3a24bb78f8fbdf6f
Appending inputPropertyHash for 'reports.junitXml.outputType' to build cache key: 0c5a7f9ee0b1630048617c6a027bb3ce
2

Hi Jose,

all of those properties influence the generated reports of the Test task, which are the output of the test task. So these very well influence the output of the Test task and therefore are part of the build cache key.

Did you experience cache misses when you where expecting a cache hit?

Cheers,
Stefan

3

Hi Stefan,

Yes - I am trying to diagnose a series of Cache misses which don’t make a lot of sense, using the Build Scan tool as my diagnostic tool.

Test tasks that are continuously re-run because of the following error:

Started after	1m 45.549s
Duration	10.893s
Class	org.gradle.api.tasks.testing.Test
 
The task was not up-to-date because of the following reasons:
Output property 'binResultsDir' file samples/trader-demo/build/test-results/test/binary has been removed.
Output property 'binResultsDir' file samples/trader-demo/build/test-results/test/binary/results.bin has been removed.
Output property 'binResultsDir' file samples/trader-demo/build/test-results/test/binary/output.bin.idx has been removed.

But I can see the content of those directories still exist on the filesystem.

Furthermore, this error only occurs when I run the gradle task from the Project root:
eg.

// Project root
./gradlew -Dorg.gradle.caching.debug=true clean test  --build-cache --scan

If I then re-run the task in the module subdirectory, everything is cached and retrieved corrected:
eg.

cd samples/trader-demo
 ../../gradlew -Dorg.gradle.caching.debug=true clean test  --build-cache --scan
4

I don’t see any error in the logs above. The logs only state that the Test task is not up-to-date since the output has been removed. Since you seem to be running clean, that is expected.

If you compare two scans via Gradle Enterprise, what are the input differences shown between the two runs? See also this section in the build scan guide which explains how to diagnose cache misses and how to make sure your build works well with caching.

5

Perhaps I didn’t explain the problem properly.

I run the following gradle command from the one of the samples directories of my project:

../../gradlew -Dorg.gradle.caching.debug=true clean test integrationTest --build-cache --scan

On 2nd execution everything correctly resolves from the Gradle Build Cache (note 3s elapsed time):

> Task :samples:bank-of-corda-demo:integrationTest FROM-CACHE
Build cache key for task ':samples:bank-of-corda-demo:integrationTest' is 4ae5b5f937a01eb903f8909207ea222e

BUILD SUCCESSFUL in 3s
69 actionable tasks: 3 executed, 5 from cache, 61 up-to-date

If I now step up to the root of my project and run the same command (this time building all other modules in my project):

./gradlew -Dorg.gradle.caching.debug=true clean test integrationTest --build-cache --scan

The specific sample which was previously cached correctly is now deemed out-of-date and all tests re-run.

Why?

6

When running from the root project, you run more clean, test and integrationTest tasks. I can only assume there is some interaction between those causing the cache miss.

Please check out the section in the build scan guide or look at the result of input comparison between the build scans of the build which should have created the cached artifact and the build scan which should have consumed the cached artifact.