chore(ci): retire auto-update-pr-branches.yml (strict=false makes it redundant)#429
Merged
Merged
Conversation
… redundant
Branch protection's `strict: true` was the only thing requiring PR branches
to be up-to-date with main before merging. With strict=false (just landed)
and ecp/cross-pr-conflict as a required check (gates against semantic
overlap with sibling PRs labeled `merge-queue`), the rebase-on-every-main-
push cycle is no longer needed:
- PRs without symbol overlap with siblings → merge in parallel as their
own CI goes green; no need to be ahead of main
- PRs with semantic overlap → ecp/cross-pr-conflict stays Pending →
GitHub native auto-merge waits
The workflow burned ~10 minutes of CI per PR per main-push (rebase
triggers full Test on 3 OS re-run). For N PRs that's O(N²) CI cost
solving a problem ecp/cross-pr-conflict solves at PR-analyze time
(one job per PR, fixed cost).
Rationale per ecp-pr-analyze.yml's own design comment:
> ecp/cross-pr-conflict status is anchored to the PR HEAD commit and
> computed against merge-base, so a base-branch update doesn't
> invalidate it.
That assumption explicitly precludes the need for rebase-on-base-move.
If a real cross-PR conflict slips through (missing-cache hole in
detect_cross_pr_conflicts after Mergify's speculative-trial backstop
was removed in #401), the final required-checks wall before release
catches it.
Contributor
ecp impact cache (0 symbols) — internal, used by
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Branch protection's `strict: true` was the only thing forcing PR branches to be up-to-date with main before merging. With `strict=false` (just landed) and `ecp/cross-pr-conflict` as a required check, the rebase-on-every-main-push cycle is no longer needed.
What changes for PR authors
What still gates merge
All 10 required checks unchanged on the per-PR axis:
Risk model
`ecp/cross-pr-conflict` has a known false-negative path: when sibling PR's impact_set isn't cached yet (race on simultaneous pushes), the check passes silently (`pr_analyze.rs:502-505`). This was originally backstopped by Mergify's speculative trial-merge — Mergify was removed in #401 so the backstop is gone.
For our scale (single-author, ~5-10 concurrent PRs) the race is rare, and the final required-checks wall before release catches anything that slipped through. Worth revisiting if PR throughput grows or main start breaking from cross-PR regressions.
Out of scope
Why admin-merge
Completes the Step 1-4 plan; sitting in the queue means tomorrow's main moves keep paying the O(N²) cost.