chore(ci): run CI and auto-publish on release/* maintenance branches - #429
Conversation
Both workflows fired only on `push: branches: [main]`, so the 0.9.1 hotfix merge into `release/0.9.x` landed with zero checks and would never have published its tag — `release.py publish` had no trigger outside trunk. Add `release/*` to the push branch filter in both workflows so a maintenance branch gets the same treatment as trunk: full CI on the merge commit, and an automatic `vX.Y.Z` tag + GitHub release when the version bump lands. `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.
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.
|
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: Organization UI 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 |
Problem
Both workflows on this branch fire only on
push: branches: [main]:.github/workflows/ci.yml.github/workflows/release.ymlSo the 0.9.1 hotfix merge (#406, merge commit
33a754f) landed onrelease/0.9.xwith zero checks, andrelease.py publish— the thing thatcreates the
v0.9.1tag + GitHub release from the## [0.9.1]CHANGELOGsection — has no trigger at all outside trunk. Left alone, v0.9.1 never
publishes and the only alternative is a hand-created tag.
Change
Add
release/*to the push branch filter in both workflows, and correctrelease.yml's header comment, which claimed the trigger was a version bumplanding on
main.Nothing else moves —
setup-uvstays atv8.3.2, which is whatci.ymlalready pins on this branch.
Effect
Merging this pushes to
release/0.9.x, which fires:release.py publish, which reads the canonical version(
0.9.1), sees nov0.9.1tag, and creates the tag + GitHub releasetargeting the branch head with the curated CHANGELOG notes.
publishis idempotent (no-op when the tag exists), so whichever branchcarries a given version first wins the tag and the other side's run does
nothing. That preserves the property the 0.9.1 hotfix plan depends on: main
can never re-tag 0.9.1 once this branch has published it.
The tag will point at this PR's merge commit rather than
33a754f. The twotrees are identical across
src/,CHANGELOG.md,pyproject.toml, anduv.lock— only workflow files differ — so the released content is exactlywhat #406 reviewed. Verified after merge.
Refs #405.