dependabot / dependabot/dependabot-core
Dependabot Groups include Unexpected Dependencies when Updating Existing PR
- Dominant language
- Ruby
- Stars
- 5.8k
- Forks
- 1.5k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 149
Description
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Package ecosystem
pnpm (applies to all)
### Package manager version
pnpm=8.9.2 (likely applies to all)
### Language version
node=20
### Manifest location and content before the Dependabot update
N/A
### dependabot.yml content
(Edited down from full monorepo config:)
```yaml
---
version: 2
updates:
- directory: /web
commit-message:
prefix: Web
package-ecosystem: npm
open-pull-requests-limit: 3
schedule:
interval: weekly
day: monday
time: '05:00'
timezone: America/Toronto
versioning-strategy: increase-if-necessary
allow:
- dependency-type: all
groups:
major:
update-types: [major]
minor:
patterns:
- '*' # everything else - minor, patch, etc.
```
### Updated dependency
N/A
### What you expected to see, versus what you actually saw
When manually updating a PR via dependabot (i.e. by running `@dependabot recreate`, or similar commands), dependencies which should not be included in the PR are added to it.
From the [documentation for groups](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups):
> Dependabot creates groups in the order they appear in your dependabot.yml file. If a dependency update could belong to more than one group, it is only assigned to the first group it matches with.
This implies that the following config snippet:
```yaml
groups:
major:
update-types: [major]
minor:
patterns:
- '*' # everything else - minor, patch, & indirect dependencies
```
Should not include "major" semver updates in the `minor` group.
However, this filtering is not applied when a dependabot run is based on an existing pull request:
#### Before:
#### After running `@dependabot recreate`:
(Note: I have no idea why this shows "with 19 updates", but this is unrelated.)
### Native package manager behavior
N/A
### Images of the diff or a link to the PR, issue, or logs
[Full dependabot run logs](https://github.com/user-attachments/files/16716962/logs_27389718635.zip)
Here are some relevant specifics:
- Two groups exist:
```
"dependency-groups":[{"name":"major","rules":{"update-types":["major"]}},{"name":"minor","rules":{"patterns":["*"]}}],
```
- Minor group is being updated:
```
"dependency-group-to-refresh":"minor"
```
- Existing PR is detected, and has one dependency:
```
"existing-group-pull-requests":[{"dependency-group-name":"minor","dependencies":[{"dependency-name":"antd","dependency-version":"5.20.2","directory":"/web"}]}]
```
- PR is recreated with major (as defined by semver) version bumps:
```
+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| Changes to Dependabot Pull Requests |
+------------------------------+--------------------------------------------------------------------------------------------------------------------------+
| closed: dependencies_changed | antd |
| created | @vitest/coverage-v8 ( from 1.6.0 to 2.0.5 ), vitest ( from 1.6.0 to 2.0.5 ), antd ( from 5.20.0 to 5.20.2 ), @vitest/... |
+------------------------------+--------------------------------------------------------------------------------------------------------------------------+
```
### Smallest manifest that reproduces the issue
```yaml
---
version: 2
updates:
- directory: /
package-ecosystem: npm
groups:
major:
update-types: [major]
minor:
patterns:
- '*' # everything else - minor, patch, etc.
```
### Debugging Help / Recommendation:
When deciding which updates may be included, this job should not only check that the dependency is applicable to the current PR's group, but _also_ verify that it is _not_ applicable to any previous group.
If a given dependency is applicable to a previous group, that group will pick up the dependency when it is re-evaluated.
This would make the behaviour consistent between an "inital" run (when no PRs exist), and an "update" run (when one or more PRs already exist).
Contributor guide
Research direction
Start with the minimal dependabot.yml configuration and the linked run logs, then reproduce the behavior with @dependabot recreate on an existing grouped pull request. Trace how dependency-group-to-refresh and existing-group-pull-requests are handled; done means major updates stay in the major group and are excluded from the minor group during recreation, matching an initial run.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, ruby
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100