ci: prune docker images before AND after deploy, not only on pull failure (#129) #130

2026-09-13T12:28:00-04:00

logan commented

2026-09-13 12:28:00 -04:00

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

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)

logan added 1 commit 2026-09-13 12:28:01 -04:00

ci: prune docker images before AND after deploy, not only on pull failure (#129 ) e97dab22ce

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 main

2026-09-13 12:28:08 -04:00

logan deleted branch fix/129-deploy-disk-prune

2026-09-13 12:28:09 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logan/server-26#130