chore(ci): run CI and auto-publish on release/* maintenance branches - #430
Conversation
Both workflows fire only on `push: branches: [main]`, so a maintenance branch gets no checks on its merge commits and its version bumps never publish. The 0.9.1 hotfix hit exactly that: it merged into `release/0.9.x` with zero checks and no path to a `v0.9.1` tag. Add `release/*` to the push branch filter in both workflows so any release branch gets the same treatment as trunk. `release.py publish` is already idempotent (no-op when the tag exists), so whichever branch carries a version first wins the tag and the other side's run does nothing.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
pbean has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 45 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughCI and release workflows now trigger on pushes to ChangesWorkflow trigger updates
Estimated code review effort: 1 (Trivial) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 8-10: Update the release workflow’s concurrency and publishing
behavior so main and release/* runs targeting the same version cannot race: use
a shared version/release-based concurrency group instead of only github.ref, or
make command_publish handle gh release create conflicts by treating an
already-existing tag or release as successful.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 92cca359-f110-45df-ab43-2fe7a171a312
📒 Files selected for processing (2)
.github/workflows/ci.yml.github/workflows/release.yml
|
@coderabbitai Verified the race and it is real, but it is out of scope for this PR — filed Confirming the mechanism rather than taking it at face value: Not fixing it here for two reasons:
One note on the suggested fix: a shared concurrency group alone does not close the window, |
|
Tip For best results, initiate chat on the files or code changes.
A shared concurrency group alone does not close the stale local-tag window. The I will treat this PR as the intended trigger-only change. 🐇 ✏️ Learnings added
You are interacting with an AI system. |
Adding the `release/*` trigger lets two branches publish, which turns `cmd_publish`'s idempotency guard into a TOCTOU. `tag_exists` is `git rev-parse` against the *checkout's* refs and nothing re-fetches before `gh release create`, so it answers for tag state at checkout time. Two runs carrying the same version could both pass it, both create, and the loser died on `check=True` — a red job for an outcome that was already correct, since the winner made this exact tag from this exact CHANGELOG section. Close it from both ends. The concurrency group drops `github.ref` so all publish runs serialize repo-wide and the second one checks out after the first pushed its tag, short-circuiting cleanly on the probe. And `gh release create` no longer runs under `check=True`: a stderr naming a duplicate tag returns 0, anything else prints the stderr and dies as before. Matching the phrase rather than the HTTP status keeps a 422 raised for some other validation failure — a malformed target, bad notes — on the loud path.
There was a problem hiding this comment.
pbean has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
1 participant
What
Add
release/*to thepushbranch filter in both.github/workflows/ci.ymland
.github/workflows/release.yml, and correctrelease.yml's header comment,which described the trigger as a version bump landing on
mainonly.Nothing else changes.
Why
Both workflows fire only on
push: branches: [main]. A maintenance branchtherefore gets no checks at all on its merge commits, and a version bump
landing there never publishes —
release.py publishsimply has no triggeroutside trunk.
The 0.9.1 hotfix hit exactly that. It was cut from
v0.9.0ontorelease/0.9.x(main carries next-major work that must not ship in a patch),merged as #406 with zero checks, and had no path to a
v0.9.1tag short of ahand-created one.
Effect
Any
release/*branch will now auto-publish on a version bump, the sameway
maindoes: pushing a merge commit that bumps the canonical version firesthe publish job, which creates the
vX.Y.Ztag and GitHub release from thematching
## [X.Y.Z]CHANGELOG section, targeting that branch's head. Thosebranches also get full CI on their merge commits for the first time.
release.py publishis idempotent — it no-ops when the tag already exists — sothe two triggers cannot fight: whichever branch carries a given version first
wins the tag, and the other side's run does nothing. That is what keeps a
forward-port of already-released content from re-tagging it.
The same change was shipped to
release/0.9.xas #429 so v0.9.1 could publish;this PR carries it to trunk.
Refs #405.
Summary by CodeRabbit