Is it possible to specify a task as cacheable locally only? I’ve noticed that tasks with very small outputs (and generally fast execution) don’t benefit much from cacheing and the RTT to remote is typically negative.

not as far as I know, but perhaps you could disable caching for those tasks in particular? even without cache, you should still have up-to-date checks that allow them to be skipped locally if the inputs/outputs haven't changed

Yeah was considering that too. It’s sort of hard for me to grok which tasks have a net benefit vs. net negative. I wish I could show avoidance savings as a column in the scan timeline (and wish i could order by savings)

https://docs.gradle.org/current/javadoc/org/gradle/work/DisableCachingByDefault.html

Not all work benefits from caching: for example tasks that only copy content around on disk rarely do.

gives a little guidance

Yeah I know this is expected behavior, it still doesn’t make it super straight forward to solve 🤷

The remembering would not make much sense. When you get an entry from remote cache it is also put to local cache afair, so the next cache use would be from local directly.

Not exactly sure? It would just mean we run the task to populate our local cache instead right? isn’t the net results still faster?

I don't get what you mean. If I got you right you suggested that Gradle automatically determines when a remote cache hit was a net negative and does not ask the remote cache again. I said this does not make sense as after the first remote cache hit you anyway get local cache hits

I don’t mean for the full cache key, but at the task level

how does it know if it ends up net-negative or not? just run every task and compare how long it takes?

i donno, probably do it on the cache server side 🤷

the cache server has no idea what any of the cache entries mean so that's even less possible 🤷

haha okay then yeah

The cache server is only a dumb file store. But the creator of a cache entry could surely add to the metadata what you can save. Actually, I think it already saves that, so that in a build scan you can already display the savings which also sometimes happen to be negative: https://scans.gradle.com/s/qf4quvqgyasda/timeline?details=5hmtaw3jwchdw&expanded=WyIxIl0&hide-timeline&kind=task&outcome=from-cache&sort=longest So such a feature might indeed be possible with not too much effort. Whether the Gradle folks deem it worth, you have to find out with opening a feature request. :-)

The savings here appear to be what you would save with task avoidance: here the task took 0.137s, with 0.130s attributed to the build cache. Had the task been UP-TO-DATE, this would have saved 0.130s. It doesn't say what build cache saved versus actually running the task though.

Are you sure?

Are you sure?

Not at all 🤣 That's just how I interpret what I'm seeing in the scan

https://gradle.com/develocity/legacy-releases/2019.4#inspect-avoidance-savings-for-individual-builds

An “avoidance saving” is an estimate of the amount of time saved when execution of a Gradle task or Maven goal was avoided due to reuse of existing outputs. It is measured as the difference between the time taken to originally do the work, and the time taken to reuse it (e.g. download from remote build cache). For Gradle builds, outputs can be reused via incremental building and build caching, while for Maven builds build caching is the only avoidance mechanism.