In one widely used bot's documentation, a dependency joins the first group whose rule it matches, and anything matching no rule gets its own pull request. If a name matches both an include pattern and an exclude pattern, it is excluded. So order your groups from most specific to least, and test the result.
The documented rules
Grouping rules in that bot combine a name pattern, an exclude pattern, a dependency type and an update level. The documentation says:
- With no groups defined, each dependency that needs updating gets its own pull request.
- With groups defined, all updates matching a rule are combined into one pull request.
- If a dependency matches more than one rule, it is included in the first group it matches.
- Dependencies that match no rule are updated in individual pull requests.
- Both pattern options support a star wildcard, and an exclude beats an include.
- A group can apply to version updates or security updates, and defaults to version updates when unspecified.
A second bot takes a different approach. Its noise guide shows a group built from a name pattern, so every package with a given word anywhere in its name lands in one branch. It also notes that its default presets already group sibling packages from known monorepos.
A worked example
Say you have these groups, in this order: all development dependencies, then everything with a framework name in it, then all patch updates.
| Package | Matches | Lands in |
|---|---|---|
| A test runner (development) | Development, patch | Development group, because it matched first |
| A framework plugin (production) | Framework name | Framework group |
| A small utility (production, patch) | Patch only | Patch group |
| A database driver (production, minor) | None | Its own pull request |
If you had put the patch group first, the test runner patch and the framework plugin patch would both have joined it. Order changes outcomes.
How to design groups
- Start with the narrowest groups, such as one named framework family.
- Add broad groups after, such as all development dependencies at patch and minor level.
- Use excludes to carve out packages that must stay individual, such as anything your code calls on a hot path.
- Keep majors out of groups unless the packages are one family. The noise guide says grouping raises the chance that a branch breaks the build, makes it harder to find the culprit, and blocks the rest of the group until all pass.
- Check the first run. Read each pull request title and list what is in it.
Security reasons for care
A group can hide a security fix inside a large pull request that fails on an unrelated package. The urgent fix then waits. Consider a separate group, or a separate rule, for security updates, and keep the group small enough that a failure points to one cause.
Test your own tool
Write down your groups in order, then pick five real dependencies and predict where each lands. Compare with the actual pull requests. If your predictions fail, your mental model of the rules is wrong, and so is any documentation you wrote for teammates.
Quick check
Does the order of group rules matter?
In the documentation we read, yes. A dependency joins the first group it matches.
What if a package matches an include and an exclude?
It is excluded from that group in the documented behavior, then updated individually unless another group takes it.
Safeguard builds an SBOM from manifests and lockfiles and uses reachability analysis to show which flagged dependencies your code calls, so you can keep exposed packages out of broad groups. Policies and gates check pull requests. Fix pull requests are off by default, with every category on Manual. Try a free scan.
Sources
- Code host documentation: update bot options reference, groups
- Update bot documentation: noise reduction and grouping
Last reviewed: 19 October 2026.
