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

(Jose Coll) #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``````

(Stefan Wolf) #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

(Jose Coll) #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

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
``````

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

``````cd samples/trader-demo

(Stefan Wolf) #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.

(Jose Coll) #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?

(Stefan Wolf) #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.