Make periodic cache cleanup retention times configurable

[wszeboreq]

Expected Behavior

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.

Current Behavior

Currently the 7/30 days retention times described in the mentioned comment are not configurable.

Context

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.

Your Environment

------------------------------------------------------------
Gradle 4.10.1
------------------------------------------------------------

Build time:   2018-09-12 11:33:27 UTC
Revision:     76c9179ea9bddc32810f9125ad97c3315c544919

Kotlin DSL:   1.0-rc-6
Kotlin:       1.2.61
Groovy:       2.4.15
Ant:          Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM:          1.8.0_151 (Oracle Corporation 25.151-b12)
OS:           Windows 10 10.0 amd64

[Niko-sk2x]

Would it be also possible to give an option to completely disable it? On a development machine where space usage is not an issue, I don't want to wait for gradle to redownload things just because I didn't actually use gradle in a week.

[marcphilipp]

@Barteks2x That's part of #6084.

[lukeu]

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.

[lukeu]

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 gradlew tasks on all the projects I want to ensure aren't "cache flushed"? Or I would actually have to build them?

[marcphilipp]

gradlew tasks would not be sufficient, you'd have to build them in order to keep the dependencies in the cache.

[Clintonio]

Just throwing in support for this issue. It will be very useful for CI agents to be able to decrease the time period for a company that has a wide range of different builds with different dependency sets but limited disc space on CI agents.