Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Make periodic cache cleanup retention times configurable #7018
Periodic Gradle cache cleanup was implemented as #1085. Comment #1085 (comment) summarizes the implemented strategy. It would be great to have various hardcoded cleanup algorithm parameters configurable, at least the 7/30 days retention times. This would give the additional flexibility and allow tuning the periodic cache cleanup to fit various possible scenarios and environments.
Currently the 7/30 days retention times described in the mentioned comment are not configurable.
Our projects use some dependency artifacts having significant disk sizes (e.g. 1 GB). Practically each day we have a new version of majority of these dependencies. This leads to '.gradle/caches/modules-2/files-2.1' grow bigger and bigger each day, leading to free disk space problems on the build servers. 30 days of cache retention time in this scenario may lead to requirement of 30 GB free cache disk space for each bigger dependency.
I praise the auto-cleanup feature, but I work on various projects (like open source, or in-house utils) intermittently. I might dip in only after 3, 6 or 12 months to tweak something. I might be offline / travelling when I do so, and suddenly I find I can't tweak something simple [Update: or even just launch the existing app from my IDE] because my day-to-day work has cleaned out required dependencies.
A thing that has hits me is that I sometimes customise Eclipse's classpath (as a pragmatic workaround or knocking up small utilities quickly) adding .jars directly from gradle's cache. I don't mind updating these occasionally (as new versions come in, old versions go away), but it would be good if I could extend the timeout so that it doesn't happen too often.
Finally, I frequently git-bisect way back in history: multiple years is not uncommon.
Disc space is a non-issue for me. I would use settings like 90/365.
Just curious about a workaround. (My main projects will likely stay on 4.10 for some time longer. And hmm.... if any side-project happens to run 4.10 I guess it would zap the cache too.)
Maybe a cron-job? Would it be sufficient to say run
For the benefit of others watching / finding this, it looks like we can disable it completely with :
Would be great to document this. (I'd been keeping an eye out for such a fix, but I missed it because the discussion here indicated it wasn't done & it appeared under "external contributions" in the 5.0 release notes, rather than closed-issues.)