Menu

#523 fix(ci): fail the release when a merge to main tags nothing

closed
nobody
None
2026-07-21
2026-07-21
Anonymous
No

Originally created by: adityaharishch

Targets main directly - the fix has to reach main to be releasable, and landing it is also what unblocks v1.75.0.

⚠️ Merge with "Create a merge commit", not squash

A squash collapses fix(ci): into whatever the PR title becomes, and semantic-release reads subject lines only - so it would find nothing to release and we would be in the same place a third time.

Why this exists

release-prepare exited 0 when semantic-release found no releasable commits.

On pre-main that is correct - a push carrying only chore/docs/ci commits legitimately cuts nothing, and the next feature merge picks it all up. On main it is a failure. The only push to main is the pre-main → main release merge, a deliberate act whose entire purpose is to ship a version. Producing no tag means the release silently did not happen, and a green check actively said otherwise.

It has now happened twice. Both [#517] and [#522] were squash-merged:

$ git log v1.74.0..main --oneline
2d1ce104 release: cut v1.75.0 (re-merge #517 with history intact) (#522)
93a8d0f5 release: staging  production (Silicon-only pipeline, warm cache) (#517)

$ git rev-list --parents -n1 2d1ce104
2d1ce104 93a8d0f5       one parent: squash, not a merge

Both subjects start with release:, not a releasable type. The real feat:/fix: commits survive only as bullets in the body, which commit-analyzer does not read. Result:

Analysis of 1 commits complete: no release
There are no relevant changes, so no new version is released.
 no releasable commits; nothing tagged

Exit 0. Green check. Production stayed on v1.74.0 while main carried the new pipeline, with nothing in the UI to indicate it.

What changes

A main push that tags nothing now exits 1 with a ::error:: and a step summary naming the likely cause and the fix - use a merge commit for release PRs, keep squashing feature PRs into pre-main. pre-main behaviour is unchanged.

Also: a self-inflicted hazard, defused

ci.yml carried a comment that quoted GitHub's skip-CI marker verbatim while explaining the version-bump commits. When [#522] was squashed, every commit body was concatenated into main's commit message, that quoted marker came along, and GitHub skipped every workflow on the merge - CI, Cache warm and release-prepare all never ran. So the merge failed for two independent reasons at once.

The comment now describes the marker instead of spelling it out. This is the same class of bug as the old [staging-release] marker documented in release-prepare.yml's own header - "this repo's own workflow comments quote the literal marker" - which is why the replacement comment points at this guard rather than repeating the string.

On merge

fix(ci): is releasable, so release-prepare should cut v1.75.0, commit the bump, push the tag, and release-build will publish the Apple-Silicon DMG (signed and notarized). The cache is already warm on main - Cache warm (macOS release) succeeded at 11:11 - so this should be the first build materially under the old ~25 minutes.

Note the payload it releases is everything already sitting on main from [#517] and [#522], which includes dropping Windows and Intel from production and #520, compulsory sign-in.

Follow-up

allowed_merge_methods on the main ruleset is still ["merge","squash","rebase"], and GitHub remembers the last-used method per repo - which is why the button keeps defaulting to squash. Removing squash there makes this failure mode impossible rather than something to remember at the moment of merging. This PR only makes it loud.

Verification

Both workflow files parse; the modified run: block passes bash -n; full pre-push suite green (fmt, clippy, UI build, UI tests, cargo test, security audit).

Related

Tickets: #517
Tickets: #522
Tickets: #526

Discussion

  • Anonymous

    Anonymous - 2026-07-21

    Originally posted by: coderabbitai[bot]

    [!WARNING]

    Review limit reached

    @adityaharishch, you've reached your PR review limit, so we couldn't start this review.

    Next review available in: 41 minutes

    Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
    You're only billed for reviews past your plan's rate limits ($0.25/file).


    How can I continue?

    After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

    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 configuration

    Configuration used: Organization UI

    Review profile: ASSERTIVE

    Plan: Pro Plus

    Run ID: 261a4941-da31-4953-ada0-6f136a3eb2dd


    📥 Commits

    Reviewing files that changed from the base of the PR and between [2d1ce1] and dae5588cbfc54bdb3311aa6326ec1e00fbb849a1.


    📒 Files selected for processing (2)

    • .github/workflows/ci.yml
    • .github/workflows/release-prepare.yml
    ✨ Finishing Touches
    🧪 Generate unit tests (beta) - [ ] Create PR with unit tests - [ ] Commit unit tests in branch `fix/release-prepare-loud-fail`

    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 - [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)

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

     

    Related

    Commit: [2d1ce1]

  • Anonymous

    Anonymous - 2026-07-21

    Ticket changed by: adityaharishch

    • status: open --> closed
     

Log in to post a comment.