fix(ci): scope RC release notes to the previous RC - #267
Open
EtienneLescot wants to merge 1 commit into
Open
Conversation
Every RC of a line shipped the same release body. The notes start tag was derived from the stable version, so v1.9.0-rc.1 and v1.9.0-rc.2 both spanned v1.8.0..<tag> — rc.2 just repeated rc.1's list plus its own few entries, and v1.8.0-rc.8 and rc.9 came out byte-identical. Testers had no way to see what a re-cut actually changed, which is the one question an RC body has to answer. Resolve the previous RC of the same line instead, walking down from the current rc number so a skipped or failed RC doesn't break the chain. rc.1 still falls back to the previous stable, and stable releases are untouched. Build the RC body from `git log` rather than --generate-notes. GitHub's generator lists only the PRs it manages to associate and silently drops real ones: #254 and #261 were merged into release/v1.9.0 yet never appeared in v1.9.0-rc.2's body, so an RC could omit the very fix it was cut for. The commit range is the actual diff. Stable releases keep --generate-notes — they are the public-facing ones and want the PR links and the New Contributors section. Needs fetch-depth: 0 on the publish job's checkout for the tags and history.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
Problem
Every RC of a line ships the same release body. v1.8.0-rc.8 and v1.8.0-rc.9 are byte-identical; v1.9.0-rc.2 repeats all 18 of rc.1's entries before its own. The one question an RC body has to answer — what changed since the last RC — is the one it doesn't.
Two independent causes:
1. The notes start tag is derived from the stable version.
STABLE_VERSION="${VERSION%%-*}"strips-rc.N, so every RC of 1.9.0 getsv1.8.0as its start tag and spans the whole release.2.
--generate-noteslists only PRs GitHub manages to associate, and it drops real ones. #254 and #261 were both merged intorelease/v1.9.0and both are in the rc.2 tag, yet neither appears in rc.2's body. Five of the eleven commits inv1.9.0-rc.1..v1.9.0-rc.2are invisible — includingfix(export): stop drawing the screen inside the PiP box on camera-less clips. An RC body can silently omit the fix it was cut for.Fix
git logover that range. The commit range is the actual diff and can't lie.--generate-notesfor PR links and New Contributors.fetch-depth: 0on the publish job's checkout, needed for the tags and history.What rc.2 would have looked like
Verification
Ran locally against the real tag graph:
rc.1 → v1.8.0,rc.2 → v1.9.0-rc.1,v1.9.0 → v1.8.0,v1.8.0-rc.9 → v1.8.0-rc.8, and an unstarted line falls back correctly.set -eo pipefail) for the prerelease path, the stable path, and an empty range — the last one being theset -erisk, sincegit logover an empty range is what a re-tag would hit. All exit 0.run:blocks passbash -n.Targets
release/v1.9.0so an rc.3 gets it immediately; reachesmainthrough the usual back-merge at promote.