the grouped security-update PR failed CI with 200 changed files - the agent couldn't tell which bump broke the build
Bisects a giant grouped security-update PR to find the single bump that broke CI, so the rest can merge while the culprit is quarantined. Use it when a grouped update PR goes red and the diff is too big to eyeball. Key trigger: grouped PR, red CI, hundreds of changed files, unknown culprit.
TL;DR: Do not revert the whole PR and do not guess - bisect it. Check out the branch, reproduce the failing CI job locally, and binary-search across the dependency changes until one bump is left standing. Merge everything else, quarantine the breaker.
the grouped security-update PR failed CI with 200 changed files - the agent couldn't tell which bump broke the buildSteps
- Identify the failing CI job and reproduce it locally on the PR branch (same test command, clean install first).
Expected: the failure reproduces outside CI - if it does not, the problem is the CI environment, not the bumps.
- List the dependency changes in the PR by diffing the lockfile, grouped by package.
Expected: a finite suspect list, far shorter than 200 files once each bump is collapsed to its package.
- Bisect: check out the base, apply half the bumps, install, run the failing test; repeat on the failing half. With a lockfile this means editing the manifest in halves and reinstalling each step.
Expected: after a handful of iterations, one bump remains that reproduces the failure alone.
- Confirm the culprit by applying only that bump on a clean base and running the test.
Expected: red with the bump, green without - proof, not suspicion.
- Merge the PR minus the culprit (revert just that bump's manifest change), and open the culprit as its own PR with the CI failure linked.
Expected: the security updates land now; the breaking bump gets its own review and timeline.
Use this when
- A grouped update PR fails CI and the diff is too large to read
- Multiple bumps landed together and one of them breaks tests or the build
- You need to decide between revert-all and finding the culprit
- Renovate or dependabot grouped PRs keep going red as a unit
Not for this skill when
- CI fails identically on the base branch - the breakage predates the PR; fix the base first
- The failure is a lockfile merge artifact (two bots collided) - regenerate the lockfile instead
- Only one dependency changed - test that bump directly, no bisect needed
Variant phrasings
- how to find which dependency update broke CI in a grouped PR
- bisect renovate grouped PR failure
- dependabot grouped security update failed tests which package
Why it happens
Grouping trades review cost for blast radius: twenty bumps in one PR means twenty suspects when CI goes red, and lockfile diffs hide which package actually changed behavior. Teams then either revert everything - losing the security fixes - or merge blind. Bisection is the mechanical way out: it treats the bumps as a suspect list and halves it until one remains.
Edge cases
- Two bumps can interact (A breaks only with new B) - if single-bump tests all pass, test pairs from the failing half.
- Flaky tests poison bisection - verify the failing test is deterministic on the base before you start, or every bisection step lies.
- Native modules and lockfile-only changes reinstall slowly - budget the time; a 6-step bisect with slow installs still beats guessing.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_sWEv9tYvkWsHOkZs6V-R7g
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.