ops: nightly prune of docker build cache older than a week - #309
Merged
Merged
Conversation
Build cache is the biggest non-database consumer on a box that builds its own images, and this one does: deploy-app.sh builds here so NEXT_PUBLIC_* never leave the box, and the other properties on dev2 build here too. In one day that cache went 0 -> 38 GB, was pruned by hand, and was back to 11.5 GB within hours — twice firing a disk alarm that had nothing to do with the databases. until=168h is the conservative part. Only cache older than a week is discarded, so nothing a current or recent build would reuse is touched and rebuild speed is preserved. A bare `prune -f` would slow the next build of every property on the box, which is why this is age-filtered rather than total. Agreed with the nichedb session first, since they are the heavier build user on shared infrastructure and a policy that slows their rebuilds is not mine to impose. Verified on dev2: the exact command reclaims 0B today, because nothing is yet a week old, and leaves the 11.5 GB working cache intact — which is the behaviour that matters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan49 finding(s) HIGH/CRITICAL: 2 | MEDIUM: 32 | LOW: 15
Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Build cache is the biggest non-database consumer on a box that builds its own images, and dev2 does:
deploy-app.shbuilds here soNEXT_PUBLIC_*never leave the box, and the other properties on dev2 build here too.In one day that cache went 0 → 38 GB, was pruned by hand, and was back to 11.5 GB within hours — twice firing a disk alarm that had nothing to do with the databases.
Why age-filtered, not a bare prune
until=168hdiscards only cache older than a week, so nothing a current or recent build would reuse is touched and rebuild speed is preserved. A bareprune -fwould slow the next build of every property on the box; the problem is accumulation over time, not the working set.Agreed first, not imposed
This is shared infrastructure and the nichedb session is the heavier build user, so a policy that could slow their rebuilds wasn't mine to decide alone. They asked for it explicitly — "a week of cache is plenty for rebuild speed and I'd rather the alarm never fires on cache again."
Verified on dev2
The exact command reclaims 0 B today, because nothing is yet a week old, and leaves the 11.5 GB working cache intact. That's the behaviour that matters — it proves the filter protects current builds rather than nuking them.