dependabot / dependabot/dependabot-core

Dependabot Groups include Unexpected Dependencies when Updating Existing PR

Open
#10,487 2 comments 3 reactions 0 assignees View on GitHub
F: grouped-updates 🎳 L: javascript T: bug 🐞
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:
Screenshot 2024-08-22 at 4 00 28 PM

#### After running `@dependabot recreate`:
Screenshot 2024-08-22 at 3 57 44 PM
(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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.