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

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.

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

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

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

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