download only caching

[xenoterracide]

I've occasionally had problems with Gradle being overly aggressive in its caching and giving me a false positive success. I want an option only to cache downloaded artifacts. Those are safe, but sometimes other things aren't.

[bigdaz]

Can you be more specific about the problems you're observing? What things are not "safe" in your opinion?

Did you consider excluding these using the mechanism described here?

[xenoterracide]

I've had bugs that I've reported to gradle where its caching was overly aggressive. Tests weren't being run when they should have been because gradle wasn't (isn't? I don't recall that issue has ever been closed) invalidating its cache properly. That's the one I remember...

The problem with excluding that way is that it implies that I know what's in each of those directories.

I'm just using --no-build-cache --no-configuration-cache and hoping that's good enough for my use case to make a slower but more comprehensive check. I still have other jobs that use faster caching.

[bigdaz]

This action merely saves and restores the Gradle User Home directory between invocations. So any issues you see with "overly aggressive" caching should also manifest when running the build locally (and not purging the Gradle User Home).

While there are occasional bugs in Gradle that can result in corrupted cache entries, the vast majority of issues with caching (particularly false positives) are due to a cacheable task that doesn't have all of the task inputs and outputs properly declared.

If you have incorrect cache configuration leading to false positive cache hits, then the brute force mechanism of --no-build-cache should work. But if you have an actual use case where this happens, it's usually better to fix it at the source.

[xenoterracide]

It's a known bug in gradle's Java plug in test stuff. Which has simply led to me having trust issues.

[bigdaz]

It's a known bug in gradle's Java plug in test stuff. Which has simply led to me having trust issues.

Interesting. I'm not aware of any such bugs, and I've worked with a lot of customers to improve their cache hit ratio.

[bigdaz]

I don't think there's a clear improvement to be made to the action at this stage.

1. Limiting the save/restore to only downloaded files will be likely less efficient (in many cases the compiled Kotlin scripts are more expensive than the artifact downloads).
2. There is already a mechanism for a user to selectively remove stuff from the Gradle User Home before caching
3. If the Gradle Build Cache is problematic, then --no-build-cache provides a way to disable it completely.

[xenoterracide]

It's a known bug in gradle's Java plug in test stuff. Which has simply led to me having trust issues.

Interesting. I'm not aware of any such bugs, and I've worked with a lot of customers to improve their cache hit ratio.

I can dig it up for you tomorrow if you want, It's one I reported. Something to do with cache invalidation not detected when you change the j unit configuration or something like that.

I changed the configuration the build continued to pass because the tests weren't being run. But the chain should have triggered an invalidation of the build cache and it didn't. Now I always keep at least one build that runs that doesn't cache things. Where the most frequent build does.

[bigdaz]

I can dig it up for you tomorrow if you want, It's one I reported. Something to do with cache invalidation not detected when you change the j unit configuration or something like that.

I'd appreciate that, thanks.

[xenoterracide]

Sorry, tomorrow was a little later, here you go https://github.com/gradle/gradle/issues/18176#issuecomment-924045104