Why should the local build cache be disabled on ci servers?


(Kamal) #1

Why does the build cache documentation recommend turning off the local build cache for ci servers?

I can think of two reasons:

  1. To make sure the CI servers’ local build caches don’t get out of sync.
  2. It assumes that the time it takes the CI servers to download build cache artefacts is negligible, or at least very small compared to the time it takes to generate the artefacts.

Are those the reasons? And if they are, when/how can reason 1 happen?


(Sterling Greene) #2

It’s mostly 2) and a little bit of 1). There was a third reason too. When this was first written, the local cache was unbounded in size, so it added a management overhead for CI servers (they would need to periodically delete the local cache). That was fixed in 4.0, but some people may not want to keep a 5GB local cache around on CI.

For 1), if a custom task claimed to be cacheable, but didn’t properly declare its inputs, it could populate the local cache on CI with the “wrong” thing. We were pretty conservative to only enable caching for tasks that properly declared everything, so if you’re using only the built-in cacheable Gradle tasks, you shouldn’t have a problem.


(Kamal) #3

Thanks.

Re 1), wouldn’t such a custom task also populate the remote cache with the “wrong” artefact, and so nothing would be lost by allowing it to also pollute its local cache?


(Sterling Greene) #4

It would make diagnosing the problem harder because it would depend on the state of the agent.