Our infra engineers are complaining that Gradle cache is taking 85% space of 1TB agent. It is Android multimodule project with mostly stable gradle version but we update plugins, write convention plugins and do other changes that might invalidate cache. Are there good tools/practices how to investigate next questions - is it normal that cache grows so big, why gradle cache for engineer's machine dramatically different, how much space should have build machine on CI that Gradle cache clean mechanism is sufficient to keep it workable?

Are you talking about #C013WEPGQF9 (where you are here) or about #CA83B1VLL. I assume you more talk about the latter one, so a bit off-topic here. How much space would be sufficient is probably really hard to tell. This most probably highly depends on what is built on those agents, how bis the things that are cached actually are, how often the cache fingerprint changes because you change the build script classpath (changing gradle version, changing build scripts, changing convention plugins, changing plugin versions, ...) You could for example also use an init script on the CI agents that reconfigures the cache retention periods, so that on the agents the cache is cleaned more aggressively as shown at docs.gradle.org/current/userguide/directory_layout.html#….

Indeed it is also question for #CA83B1VLL

Well, any change to build logic changes cache keys of course as different build script classpath can mean different outcome. So except for the toml changes (except for plugin version changes) that means all changes produce new cache entries. And that of course multplied with different branches you might build. Maybe if space is more the problem than speed on your CI, you could also consider to disable the cache on CI. 🤷‍♂️