chore(main): release 0.9.0#2178
Open
synthorg-repo-bot[bot] wants to merge 2 commits into
Open
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Contributor
Preview DeploymentURL: https://pr-2178.synthorg-pr-preview.pages.dev Built from commit |
b1ab7bc to
7e781b0
Compare
7e781b0 to
a9fc259
Compare
a9fc259 to
5c4d6d0
Compare
5c4d6d0 to
04b6510
Compare
6b1b643 to
8db1a0b
Compare
3f912a3 to
54c42d0
Compare
This was referenced Jun 1, 2026
Aureliolo
added a commit
that referenced
this pull request
Jun 1, 2026
…#2193) ## Summary The Auto Rollover workflow opened a duplicate rollover PR (#2190, now closed) for v0.9.0 even though the rollover for that version had already merged (#2177) and release-please PR #2178 already targets 0.9.0. ### Root cause The workflow re-runs on every push to main and decides "rollover needed" from `last-stable-patch >= 9`, which stays true for the whole window between the rollover merge and the 0.9.0 release (0.9.0 is not tagged yet, so last stable is still `v0.8.9`). The only guard preventing a repeat rollover PR in that window was: ```bash if git log "${LAST_STABLE}..HEAD" --format=%B | grep -qE '^Release-As:'; then ... skip ``` This **fails open**. On the 01 Jun 10:26 run, that run's checkout did not materialise the `v0.8.9`<->HEAD connection, so the range came up empty, `grep` matched nothing, the `if` was false, and the workflow fell through to `needed=true`. Every other run since #2177 merged correctly detected the trailer and skipped; only this one slipped through. The two other safety nets did not cover the window: the release-please-body guard matches a `Release-As:` trailer (the release PR body is a changelog, no trailer), and the create-step open-PR guard was moot because #2177 was already merged/closed. ## Fix - **New primary guard (history-independent).** Query GitHub directly for an already-merged-or-open rollover PR on `chore/auto-rollover-v<NEXT>`; skip if one exists. This holds regardless of local git-history completeness, which is what failed before. The branch name carries the version, so a merged `v0.(X+1).0` rollover never suppresses the next version's rollover; a CLOSED-not-merged PR (manual cancel) is intentionally not a skip. - **Git-log guard now fails closed.** Capture `git log` into a variable and skip the run if it errors, instead of an inline `git log | grep` that conflated a `git log` failure with a genuine no-match under `set -o pipefail`. A missed rollover self-heals on the next push to main; a spurious PR does not. - Kept the release-please-body guard; removed the now-duplicate `NEXT_VERSION` computation. - Updated `docs/reference/claude-reference.md` (was "three skip guards"; now four + fail-closed note) and tightened the new workflow comments to present-tense rationale. ## Test plan - `actionlint`, `zizmor`, `yamllint`: clean on the workflow. - `vale` + `lychee`: clean on the doc. - Verified locally that #2177's `Release-As: 0.9.0` trailer is an ancestor of the head that opened #2190 and that the range-grep matches with full history present, confirming the bug is the checkout-history edge plus the fail-open guard, not a logic error in the trailer match. - Walked all five auto-rollover runs since #2177 merged: four skipped correctly, only the 10:26 run fell through. ## Review coverage Pre-reviewed by 3 agents (infra-reviewer, docs-consistency, comment-quality-rot). All valid findings addressed: comment hygiene (dropped incident/migration framing and a stale issue ref), and the "three skip guards" doc drift. The infra reviewer confirmed the shell idioms (`if ! VAR=$(...)`, `printf '%s'`), the `gh pr list` jq filter, the least-privilege token/permissions, and the `NEXT_VERSION` move are correct, and that the `gh pr list` call fails closed (a GitHub API outage aborts the step into the existing failure tracker rather than risking a duplicate).
bd7fa86 to
f9ad9a2
Compare
61e8f55 to
33265e7
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
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.
Highlights
What you'll notice
What's new
Under the hood
🤖 I have created a release beep boop
0.9.0 (2026-06-03)
Features
Bug Fixes
Refactoring
Tests
CI/CD
Maintenance
This PR was generated with Release Please. See documentation.