Cleaning Gradle cache on Jenkins Servers


(Phil Swenson) #1

Gradle cache - is it a good idea to periodically “clean” the cache on Jenkins Servers?

Periodically, we have artifacts that get deleted from Artifactory that our build scripts depend on (other teams remove). The Jenkins servers continue to work as the artifacts are cached locally.

My question is three fold: 1) would gradle ever detect that these artifacts are no longer available on artifactory? 2) is it good practice to periodically delete the gradle cache so we don’t use up so much disk space for old artifacts + our build system is in sync with our repo? 3) if #2 what is the best way to have Jenkins clean the cache? (rm -rf?)


#2

To answer your questions:

  1. If the dependencies are not marked as ‘changing’, then Gradle will never automatically detect the removal of these artifacts from the repository. However, you can easily execute a build with the ‘–refresh-dependencies’ command-line option and Gradle will verify that all dependencies are indeed available. This will be done without needing to re-download the actual artifacts. Check out the user guide section on cache override options for more info.

  2. It’s unfortunate that Gradle does not currently purge the cache of old artifacts. Changing modules in particular may fill the cache with artifact files that will not be used again. Currently the only way to clean these up is to remove the files from the cache manually. We are planning to make this process automatic in the future.

  3. If only particular modules are causing the cache to grow, you could simply delete the ‘~/.gradle/caches/artifacts-N/filestore/${module-name}’ directory for each of the offending modules. This will effectively remove these modules from the cache while leaving the rest of the cache intact.


(Luke Daley) #3

There’s an existing issue for this: GRADLE-2267