Skip to content

chore(ci): run CI and auto-publish on release/* maintenance branches - #429

Merged
pbean merged 1 commit into
release/0.9.xfrom
chore/release-branch-triggers
Aug 2, 2026
Merged

chore(ci): run CI and auto-publish on release/* maintenance branches#429
pbean merged 1 commit into
release/0.9.xfrom
chore/release-branch-triggers

Conversation

@pbean

@pbean pbean commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Problem

Both workflows on this branch fire only on push: branches: [main]:

  • .github/workflows/ci.yml
  • .github/workflows/release.yml

So the 0.9.1 hotfix merge (#406, merge commit 33a754f) landed on
release/0.9.x with zero checks, and release.py publish — the thing that
creates the v0.9.1 tag + GitHub release from the ## [0.9.1] CHANGELOG
section — 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 correct
release.yml's header comment, which claimed the trigger was a version bump
landing on main.

Nothing else moves — setup-uv stays at v8.3.2, which is what ci.yml
already pins on this branch.

Effect

Merging this pushes to release/0.9.x, which fires:

  • CI on the merge commit — the first checks this branch has ever run.
  • Releaserelease.py publish, which reads the canonical version
    (0.9.1), sees no v0.9.1 tag, and creates the tag + GitHub release
    targeting the branch head with the curated CHANGELOG notes.

publish is idempotent (no-op when the tag exists), so whichever branch
carries 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 two
trees are identical across src/, CHANGELOG.md, pyproject.toml, and
uv.lock — only workflow files differ — so the released content is exactly
what #406 reviewed. Verified after merge.

Refs #405.

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.

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pbean has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

@coderabbitai

coderabbitai Bot commented Aug 2, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: abd3c0b2-56a0-4826-949a-36bad5e48fd8

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant