fix(deploy): use git's own -n limit instead of | head -20

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>
This commit is contained in:
nickviljoen 2026-05-17 15:25:38 +02:00
parent e25006039f
commit a3b3f45f01

View file

@ -96,8 +96,13 @@ fi
echo "Target: $TARGET_SHORT $(git log -1 --format='%s' "$TARGET_REF")"
echo ""
echo "Commits to apply:"
git log --oneline "$CURRENT_REV..$TARGET_REV" | head -20
CHANGE_COUNT=$(git log --oneline "$CURRENT_REV..$TARGET_REV" | wc -l | tr -d ' ')
# Use git's own line limit (`-n 20`) rather than `| head -20`: piping to head
# closes the pipe after 20 lines and makes git log exit with SIGPIPE (141),
# which `set -o pipefail` propagates and `set -e` then uses to kill the
# script silently. Only bites when the deploy batch is >20 commits — i.e.
# real prod releases. First hit observed on the v1.3.0 prod deploy.
git log --oneline -n 20 "$CURRENT_REV..$TARGET_REV"
CHANGE_COUNT=$(git rev-list --count "$CURRENT_REV..$TARGET_REV")
if [[ $CHANGE_COUNT -gt 20 ]]; then
echo " ... and $((CHANGE_COUNT - 20)) more"
fi