cmd/release: don't read pr-body file in post-release step - #423
Merged
Conversation
The 4-post-release step was failing for minor releases with: v1.20.0-pr-body.txt file not found, it needs to be present to create a release on GitHub for minor releases The '<version>-pr-body.txt' file is a local scratch file written by the 2-prepare-release step into the cilium checkout. It is never committed, and 4-post-release runs in a separate job with a fresh checkout, often days later, so the file can never exist there. Since the file only ever contains a single static line, write that line inline instead of reading it back from disk. Share it as a constant with the 2-prepare-release step so the two cannot drift apart. Patch releases are unaffected as they keep generating the release body from CHANGELOG.md. Fixes: 85cd002 ("cmd/release: fix GH release creation for minor releases") Signed-off-by: André Martins <andre@cilium.io>
aanm
force-pushed
the
pr/fix-minor-release-body
branch
from
July 29, 2026 13:51
496e1e7 to
2c4233b
Compare
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.
The 4-post-release step failed for v1.20.0 with "v1.20.0-pr-body.txt file not found, it needs to be present to create a release on GitHub for minor releases" (https://github.com/cilium/cilium/actions/runs/30454869041/job/90589118380). That file is a local scratch file written by PushPullRequest.generateSummaryFile() during 2-prepare-release. It is never committed, and release.yaml passes nothing between steps via artifacts, so 4-post-release runs in a separate job with a fresh actions/checkout — a day later in this case — and the file can never exist there. Only minor releases are affected: 85cd002 added a minor-release-only branch that reads it, while patches and pre-releases keep generating the body from CHANGELOG.md, and v1.20.0 is the first .0 release since that commit landed. The failed run produced nothing durable, since the digests commit was made locally but never pushed, so there is no pr/v1.20.0-digests branch, no digests PR and no draft v1.20.0 release.
The file only ever contains a single static line, so this writes that line inline instead of reading it back from disk, and shares it as a constant between the two call sites so the PR body and the release body cannot drift apart. The resulting draft release body for a minor release is the instruction comment, then "See the included CHANGELOG.md for a full list of changes.", then the digests. That matches the intent of 85cd002: the full changelog of a minor release exceeds GitHub's release body limit, with the v1.19.0 section measuring roughly 141 KB against a 125,000 character cap, so maintainers replace the stub with the Slack announcement by hand.
gofmt, go build ./... and go vet ./cmd/... are clean and go test ./... passes. Patch releases are untouched, verified against the shipped v1.19.6 release whose 12,221 character body is generated from CHANGELOG.md by the unchanged else branch. One pre-existing caveat this does not address: the patch path assumes "## v" is the topmost heading in CHANGELOG.md, so re-running 4-post-release before step 2's changelog commit has merged into the stable branch would silently carry the previous patch's changelog rather than failing loudly.
Once this merges, re-dispatching release.yaml with step 4-post-release and version v1.20.0 should complete the release. No cilium-side change is needed, because the workflow checks out cilium/release at main on every run, and no backport is needed as this repository has no stable branches.