ci: re-enable CI on PRs targeting stable cp-7.76.0#29986
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
Restore CI runs for pull requests whose base is `stable` (i.e. the release/X.Y.Z -> stable release PRs). PR #29305 added `branches-ignore: stable` under `pull_request:` here, which makes the `ci` workflow skip every release PR targeting `stable`. The classic branch protection on `stable` still requires the `Check all jobs pass` and `All jobs pass` status checks (both produced by this workflow), so those PRs end up `BLOCKED` in `mergeStateStatus` with no way for non-admin release managers to merge — they neither get the checks nor have bypass rights. Concretely this broke release/7.76.0 (PR #29584): no `ci` runs at all, and the merge button stays disabled. Older release PRs (29443, 29290, 29674, ...) had their release branches cut from `main` before #29305 landed, so they did not carry the `branches-ignore` line and CI ran normally. Removing only the `branches-ignore` block restores the previous trigger surface. Future release branches cut from `main` will inherit the fix; release/7.76.0 itself still needs the same removal applied directly to that branch to unblock the current merge. Co-authored-by: Cursor <cursoragent@cursor.com>
deef202 to
40d6ef5
Compare
Gudahtt
left a comment
There was a problem hiding this comment.
This change was copied from extension, where we use push triggers for release candidates instead of pull_request. This was originally done to ensure we still get builds on PRs with a conflict, but I don't know if that's still a problem we're having.
Reverting the change for now sounds good to me. We can move to a push trigger in a separate PR if we want to.
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsE2E Test Selection:
No E2E test tags are needed because no app behavior has changed. The change only affects when the CI pipeline triggers, not what it tests or how the app behaves. Performance Test Selection: |
|
Description
Re-enables the
ciworkflow on pull requests whose base isstable(the releaserelease/X.Y.Z -> stablePRs).PR #29305 accidentally added
branches-ignore: stablein.github/workflows/ci.yml, which makes the workflow refuse to run on any PR whose base branch isstable.We have branch protection on
stable, which requires theCheck all jobs passandAll jobs passstatus checks.So
Check all jobs pass/All jobs passnever appeared (nocirun) on the release PR : #29584, so the release PR currently cannot be merged.Changelog
CHANGELOG entry: null
Related issues
Refs: #29584 (release/7.76.0 PR currently blocked by the missing CI checks)
Refs: #29305 (introduced the regression)
Manual testing steps
N/A
Screenshots/Recordings
Before
N/A
After
N/A
Pre-merge author checklist
Performance checks (if applicable)
trace()for usage andaddTokenfor an exampleFor performance guidelines and tooling, see the Performance Guide.
Pre-merge reviewer checklist
Note
Low Risk
Low risk: only adjusts GitHub Actions trigger filters so CI runs on
stable-based pull requests again, with no production code changes.Overview
Re-enables the
ciGitHub Actions workflow for pull requests targetingstableby removing thepull_request.branches-ignore: stablefilter, allowing required CI checks to run on release PRs again.Reviewed by Cursor Bugbot for commit 6e0ed20. Bugbot is set up for automated code reviews on this repo. Configure here.