the dependabot agent opened 40 separate PRs instead of grouping - the

Not specified by the original author.

TL;DR: Dependabot only honors groups when it sits inside the right updates entry - nested anywhere else, it is silently ignored and you get one PR per dependency. Move the groups block under the matching package-ecosystem entry, validate the file, and the next run groups them.

the dependabot agent opened 40 separate PRs instead of grouping - the groups key was nested under the wrong key in dependabot.yml

Steps

1. Open dependabot.yml and find where you put groups - the common mistake is top-level (next to version and updates) or under the wrong ecosystem entry. Expected: you find it somewhere dependabot does not read.

2. Move the groups block so it is a child of the updates entry for the right package ecosystem:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      security-minor:
        patterns:
          - "*"

Expected: groups is indented under the ecosystem entry, not at the file root.

3. Validate the file - GitHub surfaces dependabot config errors under the repo's dependency graph Dependabot tab, or run a YAML linter to catch indentation slips. Expected: no config errors reported.

4. Wait for the next scheduled run (or trigger one) and count the PRs. Expected: related bumps arrive as one grouped PR per group instead of 40 singles.

5. Close the 40 stale singles (or let the grouped PR supersede them) so reviewers see one clean diff. Expected: one grouped PR, no leftover duplicates.

Use this when

• Dependabot opens one PR per dependency despite a groups config
• Your groups block lives at the top level of dependabot.yml
• You copied a groups example into the wrong ecosystem section
• Grouping worked, then stopped after someone edited the file

Not for this skill when

• Dependabot is not running at all (no PRs, no errors) - that is a config or permissions problem, not a grouping problem
• You want grouping in renovate - renovate uses packageRules, a different config shape
• The PRs come from snyk or another tool alongside dependabot - dedupe the tools first

Variant phrasings

• dependabot groups not working, still opening separate PRs
• dependabot.yml groups key ignored
• how to group dependabot pull requests correctly

Why it happens

Dependabot's config schema only reads groups as a child of an updates entry - anywhere else it is unknown config and silently dropped, usually with no error and no warning. YAML makes the misnesting easy: one wrong indent level and the block is structurally somewhere else. The result looks like dependabot "ignoring" your config when it is really just not seeing it.

Edge cases

• Each ecosystem entry needs its own groups block - npm groups do not apply to the pip entry.
• patterns: ["*"] groups everything including majors - pair it with exclude-patterns or update-types if majors should stay separate.
• Security updates can group separately from version updates - check which update type your 40 PRs were before tuning patterns.

Provenance

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

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

Thread query: the dependabot agent opened 40 separate PRs instead of grouping - the groups key was nested under the wrong key in dependabot.yml

TL;DR:

Not specified by the original author.

TL;DR: Batch patch and minor upgrades into one PR per group instead of one per version. Set a cap on concurrently open bot PRs and group by update type (renovate) or use grouped updates (dependabot). Maintainers review one grouped PR with one CI run; the queue stops choking and nobody mass-closes anything.

dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them

1. Close or supersede the flood: keep the newest grouped PR, close the individual patch PRs with a note that grouping is being turned on. Expected: one open upgrade PR per group instead of 30.

2. Add grouping by update type. In the renovate config, add a package rule matching patch and minor updates into named groups (for example a "patch updates" group). In the dependabot config, use groups for the same effect. Expected: the next scheduled run opens at most one PR per group.

3. Set a limit on concurrently open bot PRs (renovate prConcurrentLimit and prHourlyLimit, dependabot open-pull-requests-limit). Expected: even a misconfigured rule cannot open more than N PRs.

4. Turn on automerge only for the patch group after CI passes, keeping majors and minors manual. Expected: patches land silently; reviewers only see what matters.

5. Verify on the next schedule tick: one PR per group, CI queue back to normal length. Expected: CI minutes drop and there are zero mass-closes.

Use this when

• your agent or bot opens a separate PR per dependency version
• maintainers close bot PRs without reviewing them
• CI queue times spike on upgrade days
• patch and minor bumps drown out majors that need human eyes

Not for this skill when

• the problem is merge conflicts in a single PR, not PR count
• CI is slow on every PR regardless of bot activity (fix CI capacity, not grouping)
• you need per-version test matrices for security patches (grouping may hide a bad patch version)

Variant phrasings

• "renovate opened 40 PRs overnight and CI fell over"
• "dependabot spam: one PR per patch version"
• "how to group dependabot updates into a single PR"
• "bot PR flood choking CI queue"
• "too many upgrade PRs, reviewers closed them all"

Why it happens

Default bot configs optimize for granularity: one PR per dependency per version, because isolated changes bisect cleanly. That works until the schedule fires and 30 patch releases drop at once. Each PR burns a full CI run and demands a review click, so humans batch-close instead of reviewing. Grouping trades perfect bisectability for throughput, and patch bumps almost never need individual review anyway.

Edge cases

• Grouping patch with minor in one PR means a bad minor release hides among clean patches; keep patch and minor in separate groups if you bisect failures often.
• Security advisories can ride inside a grouped patch PR; make sure your scanner runs on the group, not just per package, before automerge.
• Automerge on grouped patches can surprise teams pinned to specific versions; check for pinned overrides before enabling it.
• If two groups conflict on the same lockfile, the bot may rebase-loop; reduce group count or widen rebase windows.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ

Thread query: dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them

TL;DR:

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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

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

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

TL;DR: