Fix deploy.sh self-modification and orphaned-container bugs (#27)

This commit is contained in:
emi 2026-07-22 00:15:33 +00:00
parent 6e655722e4
commit f7e6ce1a87

View file

@ -41,6 +41,22 @@ echo "==> Fetching $BRANCH"
git fetch --prune origin "$BRANCH" git fetch --prune origin "$BRANCH"
git reset --hard "origin/$BRANCH" git reset --hard "origin/$BRANCH"
# Re-exec: git reset --hard just rewrote this very file's bytes on disk while
# it's still running. bash reads a script via buffered, byte-offset I/O, so
# anything AFTER this point in the OLD execution can read from the wrong
# offset once the file's size/content changed underneath it -- a classic
# self-modifying-script footgun. Confirmed live: after this PR added ~15
# lines above, one deploy ran with the OLD "Building images" log lines even
# though `git status` showed the checkout correctly at the NEW commit --
# the file changed under a running interpreter, not the checkout. Restart
# fresh from the now-updated file so everything after this line is
# guaranteed self-consistent. Guarded so the second invocation doesn't
# fetch+reset+re-exec forever.
if [ -z "${DEPLOY_SH_REEXECED:-}" ]; then
export DEPLOY_SH_REEXECED=1
exec "$0" "$@"
fi
# Registry-pull cutover (repo-split Stage 6): pull the tag build-push.yml # Registry-pull cutover (repo-split Stage 6): pull the tag build-push.yml
# already pushed for this exact commit instead of building in place. Mirrors # already pushed for this exact commit instead of building in place. Mirrors
# build-push.yml's own tag computation (sha-<12 hex>) so this always resolves # build-push.yml's own tag computation (sha-<12 hex>) so this always resolves
@ -59,9 +75,15 @@ docker compose pull backend frontend
# Schema migrations run inside the backend container's entrypoint (alembic # Schema migrations run inside the backend container's entrypoint (alembic
# upgrade head) before uvicorn starts, so there's no separate migrate step or # upgrade head) before uvicorn starts, so there's no separate migrate step or
# service restart here — compose owns the process model. frontend has no # service restart here — compose owns the process model. frontend has no
# migrations (stateless). # migrations (stateless). --remove-orphans matters whenever the compose
# service topology itself changes (e.g. the old single `app` service ->
# `backend`+`frontend`, repo-split Stage 4): compose only manages containers
# for services CURRENTLY defined in the file, so a plain `up -d` leaves a
# renamed-away service's old container running and squatting its port
# forever -- confirmed live, this is exactly what blocked beta's first
# dual-service deploy ("port is already allocated").
echo "==> Starting stack" echo "==> Starting stack"
docker compose up -d docker compose up -d --remove-orphans
echo "==> Health check" echo "==> Health check"
url="http://127.0.0.1:${HEALTH_PORT}/" url="http://127.0.0.1:${HEALTH_PORT}/"