Uh oh!
There was an error while loading. Please reload this page.
fix(ci): scope RC release notes to the previous RC - #267
Conversation
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 |
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.
8d13b32 to
62c6a06CompareUh oh!
There was an error while loading. Please reload this page.
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.