When the deploy batch has more than 20 commits, the `git log ... | head -20`
pipeline closes the pipe after 20 lines. git log gets SIGPIPE (exit 141),
which `set -o pipefail` propagates, and `set -e` then exits the script
silently — no prompt shown, no error message.
Only bites for release-sized batches (>20 commits). First seen on the
v1.3.0 prod deploy: 20 commits displayed, then the script returned to
the shell without prompting. dev deploys never hit this because they
typically only have 1-3 commits ahead.
Fix: tell git to limit its own output via `-n 20`. Same display, no
broken pipe. Also swap the count-by-wc-l for `git rev-list --count`
which is more idiomatic and avoids any further pipe shenanigans.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The service takes ~4s to come up on dev (75 QC modules + 14 profiles
import on start), just over the previous 3s sleep. This caused a
false-negative rollback. Now we poll /health every 2s for up to 30s
before declaring failure; same logic for the rollback-restart path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
deploy.sh [dev|prod <tag>] handles git pull or tag checkout, reinstalls
deps only if requirements.txt changed, restarts the service, runs a
smoke test, and auto-rolls back on failure. rollback.sh reverts to the
checkpoint written by the last deploy (or to an explicit commit).
health-check.sh is a one-liner for "is the app alive?" checks.
Replaces the placeholder-config rsync-based deploy-to-prod.sh.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
