fix(launch): --pinned prunes superseded images after a healthy up (gh-#441) - #443
Merged
Conversation
Nothing ever pruned old release tags — 46GB of dead images filled the demo box's 75GB disk mid-deploy (2026-08-09, db PANIC on full device during db/34); an SD-card Pi hits the wall far sooner. Success path only (every failure bails via preflight_fail first), best-effort, until=168h keeps in-use + ~last week of releases for instant rollback; builder cache goes entirely (a --pinned box never builds). Dev flow untouched. Closes #441
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Closes #441 — today's disk-full incident, made structurally unrepeatable before tonight's Pi 4 run. 🧹
What ships
persist_compose_fileon the success path —docker image prune -af --filter until=168h(keeps everything in use + ~last week of releases for instant rollback) +docker builder prune -af(a --pinned box never builds). Best-effort: hygiene never fails a launch that already succeeded. Every failure path bails viapreflight_failbefore the prune line, so a failed upgrade leaves the previous images — the ones still running — untouched.up -d.Gh441_…, Story201 harness pattern, no docker daemon needed): retention filter present, builder prune present, prune ordered after up, and the dev flow contains no prune at all (it builds from source — pruning there would eat a developer's build layers).Verification
--pinned --dry-runplan verified by hand;bash -nclean;tools/check-doc-drift.shgreen; full suite 3,631 passed / 0 failed, 0 warnings.Note for the Pi 4
launch.sh runs from the repo checkout, not from images — once this merges, the Pi 4's fresh clone has it from boot #1. No release needed.