# Deleting cache if oversize
**URL:** https://travis-ci.community/t/deleting-cache-if-oversize/9052
**Category:** Feature Requests
**Tags:** caching
**Created:** [June 18, 2020, 2:28pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052 "2020-06-18T14:28:21Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@DanySK](https://travis-ci.community/u/DanySK)
#### Post date: [June 18, 2020, 2:28pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/1 "2020-06-18T14:28:21Z")
Long lived caches of several of my projects grow with time, reaching unacceptable levels, such as 40GB. Cronjobs prevent caches from autocleaning (and cronjobs must remain there).
I’d like a way to automatically clean a cache over a certain size. Say, for instance, that I know that if it gets past 10GB, then it accumulated so many old (and unused) packages that I’d like to clean it.
Is there a way already?
I believe a `max_size` key under `cache` would be great.
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [June 18, 2020, 2:58pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/2 "2020-06-18T14:58:21Z")
> [@DanySK](#):
>
> Say, for instance, that I know that if it gets past 10GB, then it accumulated so many old (and unused) packages that I’d like to clean it.
Nothing prevents you from doing this in the build [in the `before_cache:` phase](https://docs.travis-ci.com/user/job-lifecycle/#the-job-lifecycle). This phase is specifically intended to clean up the assets to be cached.
---
### Author:  [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)
#### Post date: [June 18, 2020, 3:17pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/3 "2020-06-18T15:17:17Z")
> [@DanySK](#):
>
> Long lived caches of several of my projects grow with time, reaching unacceptable levels, such as 40GB.
This suggests to me that there is something bad about what you are caching. Some utilities may be caching more things aggressively than they should (or we are caching too much). If you can identify what is causing this unnatural growth, I think we can all be happier.
---
### Author:  [@DanySK](https://travis-ci.community/u/DanySK)
#### Post date: [June 18, 2020, 3:42pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/4 "2020-06-18T15:42:23Z")
Sure, but a build in check would be much better than parsing the output of `du`. Or is there a better way?
Also, I’m not sure how portable it is, and I’m on a multi-OS build.
---
### Author:  [@DanySK](https://travis-ci.community/u/DanySK)
#### Post date: [June 18, 2020, 3:46pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/5 "2020-06-18T15:46:10Z")
I think I clean it quite neatly via [Gravis CI](https://github.com/DanySK/Gravis-CI/blob/master/clean-gradle-cache). The thing is that the project’s got many libraries, and they are update frequently, so the cache expands a little bit on every update.
plus, it’s a multi-OS, multi-JDK build with 4-19 jobs, so if every job has a 2GB cache it’s easy to get to 40GB overall for a branch.
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [June 18, 2020, 4:19pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/6 "2020-06-18T16:19:01Z")
The output of `du` is specifically designed to be machine-readable. Each line starts with a number (assuming `-m`), then a tab.
- So you need to look for `^(\d+)\t` regex (or equivalent).
- It can also produce a grand total line at the end with `-c`
- Then `du -smxc * | tail -n 1 | cut -f 1` will give you the raw number in MiB
`du -smxc` is available in all 3 OSes. `-0` is not available in OSX, but I guess you probably don’t have files with newlines in names (to get a `du` with one, install the `coreutils` Homebrew package. It will be available as `gdu`, or as `du` (overriding the stock one) if you also add to `PATH` according to Homebrew’s instructions).
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [June 18, 2020, 4:30pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/7 "2020-06-18T16:30:09Z")
> [@DanySK](#):
>
> The thing is that the project’s got many libraries, and they are update frequently, so the cache expands a little bit on every update.
If this is the case, you don’t actually “clean it quite neatly”. You want something akin to `brew cleanup` which checks actual metadata about what’s in use (or make some other tool used in the build produce some kind of trace info about what’s in use, then use the resulting list).
---
### Author:  [@DanySK](https://travis-ci.community/u/DanySK)
#### Post date: [June 18, 2020, 4:52pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/8 "2020-06-18T16:52:16Z")
I disagree. There’s no way in Gradle to do what you suggest. It caches all the libraries in the user home, and you got no clue which are used in which phase.
Or actually, you could ask the tool, and then write a software that does the inspection for you, and that would be way more expensive than just let the cache expand until the build fails and then clean it up manually for a hundred years.
Anyway, if you got another suggestion similar to the majestic one on the use of `du` that also cleans the gradle cache selectively, I’d be glad to learn.
Cheers
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [June 18, 2020, 4:59pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/9 "2020-06-18T16:59:44Z")
> [@DanySK](#):
>
> Anyway, if you got another suggestion similar to the majestic one on the use of `du` that also cleans the gradle cache selectively, I’d be glad to learn.
Googled on “clean up gradle cache of unused packages”:
>
>
> Gradle cache folder does not have eviction policy and can take all disk space. I…t is especially problematic if using many large changing modules as dependencies.
>
> \### Expected Behavior
> Gradle should provide a way to cleanup old cached SNAPSHOT dependencies.
> For example it can be configurable how many old snapshots to keep. Other solution can be to delete dependencies that are not used for a set period of time.
>
> \### Current Behavior
> Currently files from Gradle cache are never deleted
>
> \### Context
> With time cache takes all available disk space, especially on build servers.
>
> See the original issue on https://issues.gradle.org/browse/GRADLE-2267
>
>
---
### Author:  [@DanySK](https://travis-ci.community/u/DanySK)
#### Post date: [June 18, 2020, 5:25pm UTC](https://travis-ci.community/t/deleting-cache-if-oversize/9052/10 "2020-06-18T17:25:38Z")
Thank you for the syntactic match on a search engine.
The first one is interesting, but if it works automatically, then my caches should be already cleaned up by the daemon (in addition to the cleaning I perform to prevent the cache from being repackaged at every run). I may force a `--stop` in `before_cache` and see if it improves - maybe the deamon doesn’t get shut down correctly automatically.
Unfortunately, the latter two links you posted are on entirely another topic. Pruning unused dependencies in a single project does not mean cleaning up the dependency cache from the home folder of a system. It is entirely different (and dependencies are regularly maintained).
Let me explain: every Gradle run caches the downloaded jars (and other stuff that I delete already) in the home folder.
If I use dependency X 1.0, it gets cached.
If I upgrade to X 2.0, it get cached as well, but X 1.0 does not get deleted as Gradle has no mean to know it is not used by another project, or still by the same project in a different lifecycle phase – but to wait and see if it has never got accessed for a long time (which looks like being the strategy of the first link).
A proactive search of unused cached libraries (not dependencies to prune) would require a new tool, AFAIK.