ci: fix release-notes step SIGPIPE on first release#133
Merged
Conversation
The v0.1.0 release pipeline succeeded through all 21 build/sign/verify steps but failed at step #22 ("Generate release notes"), skipping step #23 ("Create GitHub Release") as a result. The signed images were pushed to GHCR and release.json was generated and signed correctly; the only missing artifact is the GitHub Release page. Root cause: `git log ... | head -200` under `set -euo pipefail`. When `head -200` closes its stdin after the 200th line, `git log` gets SIGPIPE and exits 141. `pipefail` makes the pipeline inherit that exit code; `set -e` propagates it as script failure. This only manifests on the FIRST release for a fork: - PREV_TAG resolves to empty (no prior semver tag), so RANGE is just the current tag (e.g. "v0.1.0") - `git log v0.1.0` emits one line per commit in the entire branch history (271+ for ProcessGit's Gitea-derived tree) - head -200 truncates → SIGPIPE → step fails On every subsequent release, PREV_TAG is set and RANGE becomes "vX.Y.Z..vA.B.C", which yields a short log that head never needs to truncate. Fix: cap at the source via `git log -n 200 ...` and drop the `| head -200` pipe entirely. Same output, no SIGPIPE risk, no need to relax pipefail for this block. After this lands, the recovery is: - Delete the v0.1.0 ref (the failed run's tag) - Re-create v0.1.0 against the new main HEAD - Workflow re-runs; image build hits the warm GHA cache from this run (~30s instead of ~10min); release.json regenerates; Create-Release step now succeeds. The previously-pushed signed images on GHCR remain valid and verifiable — this fix only addresses the GitHub Release page creation. Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ci: fix release-notes step SIGPIPE under
set -o pipefailThe v0.1.0 release pipeline succeeded through all 21 build/sign/verify steps and failed only at step #22 (
Generate release notes), causing step #23 (Create GitHub Release) to be skipped. The signed Docker images are already on GHCR (cosign-verifiable); the only missing artifact is the GitHub Release page itself.Root cause
Under
set -euo pipefail:head -200closes its stdin after the 200th linegit logwrites line 201, gets SIGPIPE, exits 141pipefailmakes the pipeline return 141set -epropagates it as a script failureThis is a first-release-only bug:
PREV_TAGis empty (no prior semver tag), soRANGEis just the current tag (e.g.v0.1.0)git log v0.1.0emits one line per commit in the entire branch history (271+ commits in this Gitea-derived tree)head -200truncates → SIGPIPE → step failsOn every subsequent release,
RANGEbecomesvX.Y.Z..vA.B.Cand the log is naturally short —headnever needs to truncate.Fix
Cap at the source:
Same output, no SIGPIPE risk, no need to relax
pipefailfor this block. One-line change.Recovery procedure (post-merge)
I'll handle this via API after merge:
v0.1.0refv0.1.0against new main HEADExpected wall clock: 3-5 min.
What still works from the failed run
ghcr.io/algomation-ai/processgit:0.1.0— signed multi-arch image, pullable nowghcr.io/algomation-ai/processgit-updater:0.1.0— signed sidecar image, pullable nowBoth are signed identically (cosign keyless via OIDC). The retry will produce a new identical image (same source), and either old or new will verify against the workflow's certificate identity.
Diff