This message was deleted.

Easiest might be to use a build

--scan

. If you cannot, maybe

-Dorg.gradle.caching.debug=true

might help iirc.

I did scan and I'm checking the report now

Hm, might be that it only works with an own Develocity instance where you can compare two builds.

Aha, clear!

I guess this is the guide you meant you were using already: https://docs.gradle.org/current/userguide/build_cache_debugging.html#helpful_data_for_diagnosing_a_cache_miss? So

-Dorg.gradle.caching.debug=true

did not help?

Cool missed it!

Nice

The Build Validation Scripts would be the way to do this, but they require Develocity.

Oh, didn't I see in the readme it works without too?

Former.

That's the readme I meant

Sorry I meant former. It requires a full Develocity. 🙂

But I guess exactly that analysis can then not be done

At a minimum the scripts require build scan publishing to a full Develocity server (i.e. not

<http://scans.gradle.com|scans.gradle.com>

). The reason is for the experiment to really be useful you need the comparison feature, which as you pointed out earlier, is only available in the full version. Additionally, if you have API access to said Develocity server, the experiment summary will contain some data on the experiment outcome (e.g. # of executed cacheable tasks in the second build). This API access is not strictly required as you can always view the published build scans.

Ah, I see. Thanks for the clarification

Aha, thanks because I thought that at least first scripts will work without Develocity

Perhaps there is room for improvement here in the docs. Thanks all. That being said, I agree with Vampire that

-Dorg.gradle.caching.debug=true

would be the way to go if you do not have access to Develocity.

I tried and we have 180 modules. It is ages to wait till the finish and after trying to find things.

Is there also a way to compare two artifacts under

~/.gradle/caches/build-cache-1

? It seems the generated files use

application/gzip

MIME type Wondering if this can help in debugging cache misses with respect to Remote build cache. (since I don't have Develocity)

tar does not compress files, they just pack multiple files into one file. Hence tar files are often compressed using gzip or bzip2 or others. The

tar

tool can even do that for example with

-z

for gzip or

-j

for bzip2. But I don't think you gain much in comparing those files, afair they contain a little bit metadata like when and where it was built and other than that the outputs that are cached in that entry. To compare cache misses without Develocity, it is much more useful to run both builds with

-Dorg.gradle.caching.debug=true

and compare the fingerprint contributors to find the differences, as mentioned above already.