Fixes#129. The 2026-09-12 deploy of #126 failed instantly on the VM disk being 100% full (git pull could not write objects) — rollback never ran because the failure was before a rollback target got captured. Root cause: image pruning only ran after a successful compose pull, or as a retry after a failed one; a failure earlier than that (this one) never reached either.
Moves an unconditional docker image prune -af to the top of the deploy (before git pull), and upgrades the post-up -d prune from -f (dangling only) to -af (all unused, which is what actually caught the 96 stale SHA-tagged images from past deploys). Both are safe by construction — prune -a never removes an image a running container references, so nothing serving traffic can be pruned mid-deploy.
Manually reclaimed 23.76GB on the VM same day and re-ran the stuck #126 deploy via the Gitea API rerun endpoint; this PR is the durable fix so it does not recur.
Fixes #129. The 2026-09-12 deploy of #126 failed instantly on the VM disk being 100% full (git pull could not write objects) — rollback never ran because the failure was before a rollback target got captured. Root cause: image pruning only ran after a successful compose pull, or as a retry after a failed one; a failure earlier than that (this one) never reached either.
Moves an unconditional `docker image prune -af` to the top of the deploy (before git pull), and upgrades the post-`up -d` prune from `-f` (dangling only) to `-af` (all unused, which is what actually caught the 96 stale SHA-tagged images from past deploys). Both are safe by construction — prune -a never removes an image a running container references, so nothing serving traffic can be pruned mid-deploy.
Manually reclaimed 23.76GB on the VM same day and re-ran the stuck #126 deploy via the Gitea API rerun endpoint; this PR is the durable fix so it does not recur.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The 2026-09-12 deploy of #126 failed instantly -- git pull on the VM hit 'No space left on device' before the deploy script could even capture a rollback target. Every deploy leaves 3 freshly SHA-tagged images that only got cleaned up by a prune gated on a failed compose pull; a failure earlier than that (like this one) never reached it. 96 of 100 local images were unreferenced, 23.76GB reclaimable, disk at 100%.
Move an unconditional docker image prune -af to the top of the deploy, before git pull, and upgrade the post-up -d prune from -f (dangling only) to -af (all unused) so stale tagged images stop re-accumulating. Both are safe: prune -a never touches an image a running container references.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Tbknwttzou4s46PAykmtix
logan
merged commit 76db41adf7 into main2026-09-13 12:28:08 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #129. The 2026-09-12 deploy of #126 failed instantly on the VM disk being 100% full (git pull could not write objects) — rollback never ran because the failure was before a rollback target got captured. Root cause: image pruning only ran after a successful compose pull, or as a retry after a failed one; a failure earlier than that (this one) never reached either.
Moves an unconditional
docker image prune -afto the top of the deploy (before git pull), and upgrades the post-up -dprune from-f(dangling only) to-af(all unused, which is what actually caught the 96 stale SHA-tagged images from past deploys). Both are safe by construction — prune -a never removes an image a running container references, so nothing serving traffic can be pruned mid-deploy.Manually reclaimed 23.76GB on the VM same day and re-ran the stuck #126 deploy via the Gitea API rerun endpoint; this PR is the durable fix so it does not recur.
🤖 Generated with Claude Code