Dependabot-core: Add grouped updates

[anym0us]

Our company is migrating to Dependabot from another similar tool (Depfu).

One of the features we miss is grouped updates (when all available updates are merged into 1 PR). Here's how the option is configured for every repository in Depfu's settings (just for example):

[greysteil]

Thanks for the feedback @anym0us. We love the Depfu folks and I was really sad we were in competition with them.

We don't have support for grouped updates yet, so if that's a feature you really need I recommend you stick with Depfu for now. We'll get there on it, but it's just not the way Dependabot currently works.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[frangio]

I'm really interested in this feature to reduce the number of Dependabot PRs. I see that the PR was pinned a month ago. Would it possible to clarify whether this is in the roadmap? Thanks!

[tuan-bui]

We're interested in this feature as it makes it a lot easier to view it all in one PR. Wondering when it is planned for release also, cheers!

[JeremyTX]

We're also interested in this feature. If there are any estimates, it would be much appreciated!

[RichiCoder1]

PR simplicity + less notification noise + less Github Actions minutes spent processing dep PRs :)

[rbright]

Beyond reduction of PR noise and build cost, grouping would be valuable for libraries that need to be updated together for purposes of compatibility.

For example, updating a single AWS CDK package can lead to test failures due to API compatibilities with other CDK packages. Upgrading them all at once generally mitigates this issue.

Until update grouping is possible, we have to disable CDK auto-updates and apply them manually.

[mbrevda]

Same for react + react-dom - these always need to be updated in tandem.

[mockdeep]

I would love to see something like this. It could actually be really useful to have all minor/patch updates grouped in one PR, and separate PRs for major version updates.

[scottrobertson]

Grouping across directories would be amazing. Every time there is a release, we get one PR per directory, and it gets a bit crazy.

[jonathanong-houzz]

would love to see this for jest, babel, react, and storybook packages as they all use lerna and you generally need to update all the packages at once

[WyriHaximus]

Would love to see this. Having it grouped by vendor would be amazing, projects like Symfony tag all their packages at the same time so it rains updates, having all those combined into one PR saves us so much more time <3

[sandersiim]

Definitely would like to see this for babel and similar updates. We were using Renovatebot before, which did this nicely with "babel monorepo" updates.

[hackel]

I really hope this issue is being prioritized. Since adding Dependabot, I've found it to actually be a productivity killer—the opposite of its intended use. Instead of individually merging 10-15 PRs every other day, I've gotten in the habit of using it merely as an update notifier and manually updating dependencies myself in a single commit. Even in this workflow it still causes a lot of spam in our list of pull requests, though. Trying to look through the closed PR history becomes a real challenge.

[RichiCoder1]

That's essentially what we're considering now. Using dependabot as a vuln notifier, but actually manually managing updates or using renovate's self-hosted mode with actions since it has grouping support.

[bhearsum]

I know this is a bit of a pile on at this point - but the other pain point I'd like to point out is how many CI cycles get wasted due to this. Every PR dependabot sends to a repo triggers CI. For those of us that prefer to group updates (or need to, often because of multiple dependencies needing to update at the same time), this means 50, 100, or even more CI runs that necessary can happen every single week.

[martingjaldbaek]

I was missing this feature too, so I created a GitHub workflow to automatically combine/group all Dependabot PRs together into a single PR. I figured others could benefit from it too, so I made it available here: https://github.com/hrvey/combine-prs-workflow

Edit: Be aware that since this workflow uses git, the usual limitations of git's auto-merge apply, so it only works when there are no merge conflicts. Specifically, for Dependabot these tend to happen in the .lock file when dependencies A and B get updated and indirectly update their shared dependency C to two different versions. So clusters of modular framework components will tend to trip over this (if they all share common dependencies), while independent packages will be fine to group this way.

[JLLeitschuh]

Hi,

I was the one who recently reported and disclosed the vulnerability in JUnit 4.

It seems that by doing so I've caused Depenabot to generate over 290,000+ pull requests (and counting).
https://github.com/search?o=desc&q=Bump+junit+from+to+4.13.1+GHSA-269g-pwp5-87pp&s=&type=Issues

There are over 1,508,273+ usages of JUnit 4 according to the GitHub Dependency Graph.

Due to this vulnerability, one of the projects we maintain at Gradle ended up having 101 pull requests generated for it to fix each individual POM.xml file.
https://github.com/gradle/performance-comparisons/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+junit

There is absolutely no way that you can sanely merge 100+ pull requests using the GitHub UI currently. Thus, we were forced to create a seperate PR and close the 101 dependabot generated PRs.

We're not the only ones experiencing this issues, it is reflected on twitter by various others:

• https://twitter.com/sormuras/status/1316010270590812160
• https://twitter.com/headius/status/1316055330657243142?s=20
• https://twitter.com/MarcNuri/status/1316067844602331136?s=20
• https://twitter.com/CedricChampeau/status/1315918744036741120?s=20
• https://twitter.com/olamy/status/1315908629954916352?s=20

---

IMHO, if dependabot is going to generate over 10 PRs against a single project for the same dependency, it should consolidate it into one PR with an optional command to explode the PR into individual PRs should the maintainer wish for that instead.

A command like dependabot separate would work well here.

[neverendingqs]

For anyone looking for a Node alternative to this issue, I created a GitHub action that mimics what is asked here: https://github.com/neverendingqs/gh-action-node-update-deps.

It uses npm-check-updates and hub to create a pull request with updates to all dependencies. It's not as feature-rich as dependabot, but leaving security updates enabled and running this weekly has been sufficient to keep my dependencies updated.

[AviVahl]

In several repositories (while not in others), dependabot started grouping react and react-dom:
https://github.com/wix/potato-bruce/pull/145

Is the dependabot team experimenting with this? Would be great to have a way to specify npm scopes that update together (@jest, @babel,etc.)

[ChrisCates]

I've written a potential spec here.

https://github.com/dependabot/dependabot-core/issues/2672

I'm not really sure what the status is on this feature. But it would be nice to have these updates in.

[wangyun1517]

We have introduced dependabot into my company's GHE. After some team start to use it, they complained a lot about the PR hells.

The group feature will make our life easier.

[fkirc]

I would prefer if grouping could be configured on a per-organization basis:

For example, I get a lot of PRs for @types-dependencies, e.g. @types/node, @types/lodash and so on.
Even in small projects like attranslate, I get quite a lot of @types-PRs: https://github.com/fkirc/attranslate/pulls?q=%40types+

Those @types-dependencies are not super-critical because they do not change any runtime-behavior, therefore it would be easy to merge multiple @types-dependencies in a single PR.
If I could configure a grouping for the @types-organization, then this would be already a huge help to reduce noise and overheads.

Of course, @types is not the only organization that is good for grouping.
For example, @stephanvierkant pointed out that @symfony could be a good grouping-candidate as well:
https://github.com/dependabot/dependabot-core/issues/2265#issuecomment-626533927

Another example is https://capacitorjs.com/:
I have multiple dependencies of the @capacitor-organization (Core, CLI, Android, iOS,...).
Whenever Capacitor releases a batch of updates, then I do not only want to merge all of those, but I also need to merge all of those in order to have a consistent Capacitor-setup.

In fact, I consider it as a common practice that many npm-organizations do simultaneous releases of multiple closely-related packages, in some cases even packages with the exact same version-numbers.

Therefore, it seems natural to make organization-grouping configurable instead of hardcoding a specific behavior.

[dudo]

I'd like to see "group patch updates", nested under "group minor updates", nested under "group major updates". I can't imagine most would use the major, but for hobby projects, maybe. Still seems like a simple config, and already plays well with the existing "auto merge" config.

[n1ru4l]

I also agree that updating should be configurable. E.g. all @aws-cdk/*-scoped packages are released at the same time. However, other scoped packages could be less dependant on each other.

[cecilemuller]

Personally what I miss most is a way to group in a single PR the update of a single dependency that is used in multiple package.json (instead of having one PR per package.json).

[vladkosinov]

The biggest pain we have that once you merge one PR you need to rebase (which is crucial to not get broken dependencies tree) others one by one and wait for tests to pass each time.

When you have, let's say, 6 PR from dependabot and your tests take ~10 minutes to merge all PRs you need to wait one hour.

It could help if there would be an auto-merge feature to not struggle with merge manually, but dependabot lost it during the migration to GitHub: https://github.com/dependabot/dependabot-core/issues/1973 (and it's not an option to workaround this with GitHub Actions since we've got our own CI infrastructure)

dependabot's support for private registries is currently (https://github.com/github/roadmap/issues/67) vendor-locked to Github Packages, which is one of the main reasons pushed our company to migrate to GitHub packages. But since dependabot has no auto-merge and no grouping it's now faster and easier to bump dependencies locally than struggle with PRs rebasing hustle. This makes dependabot useless 😢

[n1ru4l]

One thing to add is that renovate can even detect packages that belong together that are not in the same repository or follow any organization scoping.

See https://github.com/dungeon-revealer/dungeon-revealer/pull/889 as an example.

[Anthchirp]

For information: https://github.com/github/roadmap/issues/133

[0rvar]

For information: https://github.com/github/roadmap/issues/133

@Anthchirp that is a completely unrelated and orthogonal feature.

[JLLeitschuh]

It's actually not unrelated, this roadmap item should actually alleviate some of this pain. Unfortunately, I can't say more at this time.

[ChrisCates]

It's actually not unrelated, this roadmap item should actually alleviate some of this pain. Unfortunately, I can't say more at this time.

@JLLeitschuh, I agree, however the most important question is how the team at Github feels about all of this.

I'm only willing to give a hand because it's clear how beneficial these tools could be to the public... For example, the potential to integrate UIX buttons to generate dependabot configurations directly into the Github UI would be great for newer and casual developers.

However, these are features that need to be something Github is willing to accept. And we haven't heard from them for a while.

[thepwagner-smurf]

I created a GitHub action that mimics what is asked here
It's not as feature-rich as dependabot, but leaving security updates enabled and running this weekly has been sufficient to keep my dependencies updated.

Me too! These Actions also implement this request:

• https://github.com/thepwagner/action-update-go
• https://github.com/thepwagner/action-update-docker
• https://github.com/thepwagner/action-update-dockerurl

There's no detection, but dependencies can be grouped by regular expression - sample.
You can also set a "cooldown" period for particular groups, so the Action can be scheduled daily, without getting ~daily PRs from projects like https://github.com/aws/aws-sdk-go/tags . I hadn't thought about grouping by the version diff (e.g. patch, minor, major), cool idea!

These actions are unsupported, but maybe a useful starting point.

[GaboFDC]

There is a lot of feedback from the community here but still no word from GitHub or maintainers.
A response would be appreciated, even if you say you are just considering it and may take really long to implement but at least some kind of reply would be nice.

[jurre]

There is a lot of feedback from the community here but still no word from GitHub or maintainers.

A response would be appreciated, even if you say you are just considering it and may take really long to implement but at least some kind of reply would be nice.

Heya, maintainer (and Huber) here.

We'd like to support this, but it would currently indeed take really long to implement so we've not been able to prioritize it. It's on our radar and backlog but I'm not able to give a timeline for when it might land.

[rhymes]

I'm not sure how this happened but we got a grouped update from dependabot at Forem https://github.com/forem/forem/pull/11990 :

Bumps flipper-ui, flipper-active_record and flipper. These dependencies needed to be updated together.

[mbj]

@rhymes Its very likely the dependencies that where bumped in your case where strongly connected and dependabot had no option to just bump all of them the same moment.

[jpbourgeon]

May I suggest a cumulative approach ?
Dependabot tries to merge dependencies updates in a targeted PR based on a criteria (dependabot dedicated PR, latest opened PR, SEMVER level major/minor/patch as suggested by @dudo, other way?) ; if the update is successfull it keeps stacking. If a specific dependency fails to merge, the PR is rolled back and a new PR is opened for manual investigation.