deploy.yml: run the superseded check after the #129 pre-deploy prune (server-26#167)

The tip check's git fetch ran before the disk-relief prune that #129 says
must be the first thing a deploy does; on a full disk the fetch could fail
and skip the prune. Prune only removes unreferenced images, so running it
on a run that then turns out superseded is harmless.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Logan Cusano
2026-10-04 18:07:08 -04:00
co-authored by Claude Opus 5.5
parent 71ee6101a1
commit 06f01ebbe0
+16 -14
View File
@@ -112,20 +112,6 @@ jobs:
set -e set -e
cd /opt/drb cd /opt/drb
# server-26#167: only main's tip deploys. Serialising (the job's
# concurrency group) stops two runs overlapping, but not an older
# run going AFTER a newer one (its build finished later, or someone
# re-ran it), which would silently roll prod back. A superseded run
# exits clean before touching anything; the newer run carries this
# commit's changes anyway. To deliberately put an older build back,
# use TAG=<sha> by hand on the VM, not a re-run.
git fetch -q origin main
MAIN_TIP=$(git rev-parse origin/main)
if [ "$MAIN_TIP" != "${{ gitea.sha }}" ]; then
echo "SUPERSEDED=$MAIN_TIP"
exit 0
fi
# server-26#129: every deploy pushes 3 freshly SHA-tagged images and # server-26#129: every deploy pushes 3 freshly SHA-tagged images and
# nothing ever removed the old ones except a prune that only ran # nothing ever removed the old ones except a prune that only ran
# AFTER a successful `compose pull` -- so a run that never got that # AFTER a successful `compose pull` -- so a run that never got that
@@ -141,6 +127,22 @@ jobs:
# block a deploy that doesn't actually need the space this time. # block a deploy that doesn't actually need the space this time.
docker image prune -af || echo "WARNING: pre-deploy image prune failed (server-26#129) -- disk pressure may persist" docker image prune -af || echo "WARNING: pre-deploy image prune failed (server-26#129) -- disk pressure may persist"
# server-26#167: only main's tip deploys. Serialising (the job's
# concurrency group) stops two runs overlapping, but not an older
# run going AFTER a newer one (its build finished later, or someone
# re-ran it), which would silently roll prod back. A superseded run
# exits clean before pulling or restarting anything; the newer run carries this
# commit's changes anyway. To deliberately put an older build back,
# use TAG=<sha> by hand on the VM, not a re-run. Runs AFTER the
# server-26#129 prune above on purpose: on a full disk `git fetch` can
# fail too, and that prune must stay the first thing a deploy does.
git fetch -q origin main
MAIN_TIP=$(git rev-parse origin/main)
if [ "$MAIN_TIP" != "${{ gitea.sha }}" ]; then
echo "SUPERSEDED=$MAIN_TIP"
exit 0
fi
# Update compose files + mosquitto config # Update compose files + mosquitto config
git pull origin main git pull origin main