agent grouped 15 unrelated majors into one PR and CI failed on four of them; nobody could tell which bump broke what

TL;DR: Split unrelated majors into one PR per major (or per tightly-coupled package pair). Bisect the failed group by reverting to a passing set and re-adding bumps one at a time, keeping the green ones. Grouping majors together saves PR count but destroys diagnosability; majors are exactly the bumps that need isolation.

agent grouped 15 unrelated majors into one PR and CI failed on four of them; nobody could tell which bump broke what

1. Freeze the mess: do not merge the grouped PR. List every major bump it contains with its old and new version.

Expected: a clean inventory, for example 15 lines of package, from-version, to-version.

1. Bisect: create a branch with the bumps applied one at a time (or in small batches), running CI after each, and keep a running list of which bump turns CI red.

Expected: the four breaking bumps identified individually.

1. Land the green bumps first as separate PRs, then open one PR per breaking bump so each gets its own review and fix.

Expected: 11 bumps merged cleanly, 4 isolated PRs with clear failure context.

1. Change the agent's grouping rule: group patch and minor freely, but keep major updates ungrouped (one PR per major), except for known lockstep pairs.

Expected: future majors arrive isolated and bisectable by construction.

1. For the four breaking bumps, attach each PR with the failing CI log excerpt and the minimal repro, not the 15-package diff.

Expected: reviewers see one failure with one cause per PR.

Use this when

• a grouped upgrade PR fails and the cause is unclear
• the agent groups major versions together
• CI is red on several packages inside one PR
• you need to know which bump broke what

Not for this skill when

• the grouped PR is green (merging it is fine; the risk was theoretical)
• the failures are clearly all from one bump already (just split that one out)
• your CI cannot run per-PR at all (fix CI before worrying about grouping)

Variant phrasings

• "grouped major upgrades failed, can't tell which broke"
• "renovate grouped 15 majors CI red"
• "how to split a failed grouped upgrade PR"
• "too many majors in one PR"
• "bisect grouped dependabot PR"

Why it happens

Grouping optimizes for PR count: fewer PRs, fewer CI runs, less review overhead. That math works for patches, where failures are rare and independent. Majors break things by design, and when four of fifteen break at once their failures interact - one package's new API breaks another package's tests, and the combined diff hides which break came first. Isolation is the only reliable diagnostic.

Edge cases

• Lockstep packages (react and react-dom, babel scoped packages) must stay together even as majors; splitting them creates guaranteed breakage.
• Bisecting 15 majors one at a time costs 15 CI runs; batch the green candidates in groups of 3-4 once you have a passing baseline, and split only the red batches.
• A "green" bump can still break a later bump's tests through shared transitive deps; re-run the full set after landing the greens.
• If the agent regroups the split PRs on its next run, pin the grouping config change before re-running it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2T6CvqBAHLm0R7N82ncIYA