Originally created by: adityaharishch
ci.yml ran on pull_request into main as well as pre-main. Scoped to pre-main only.
The only PR that ever targets main is the pre-main → main release merge. Running the suite there re-tests a tree it has already passed twice - once on each commit's own feature PR, once on the push to pre-main.
main holds nothing pre-main lacks except version bumps:
5fcc25c9 chore(release): 1.74.0 [skip ci]
ec751d73 chore(release): 1.73.0 [skip ci]
99b7499d chore(release): 1.72.0 [skip ci]
So the merge introduces no code that has not already been through CI.
This is not the same situation as a feature PR. There, the PR run tests your branch against the pre-main of that moment, and someone else's PR can land before yours - two independently green branches combining into something broken. The post-merge push run is what catches that semantic conflict, and it stays exactly as it was. A release merge has no second code stream, so there is no conflict surface for a re-run to find.
While a pre-main → main PR is open, pre-main is that PR's head branch. Every push to pre-main therefore fired the whole suite twice - once as push, once as pull_request for the open release PR - including Rust (macOS Apple Silicon), the slowest and most expensive job in the workflow. That doubling ran for the entire life of every release PR.
push: [main, pre-main] - production still gets a full run on the merge commit. This is the signal that matters for main, and it now runs once instead of twice.migration-guard was already pull_request-gated (if: github.event_name == 'pull_request'). It now scopes to PRs into pre-main, which is where migrations actually enter the codebase - it was never able to run on a release PR's push event anyway.if: conditions were touched.None of these checks are required today regardless - the main ruleset enforces only required_approving_review_count: 1, with no required_status_checks rule. The real gate on a release is human: has pre-main been exercised end to end on the staging DMG, per CLAUDE.md's "PR target branch" section. No status check can express that.
Originally posted by: coderabbitai[bot]
✨ Finishing Touches
🧪 Generate unit tests (beta)
- [ ] Create PR with unit tests - [ ] Commit unit tests in branch `ci/skip-redundant-main-pr-checks`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 helpto get the list of available commands.Ticket changed by: adityaharishch