Dependabot-core: Support grouping of pull requests

[greysteil]

See https://github.com/dependabot/dependabot-core/issues/376 for more detail.

[dwieeb]

I would love to have @dependabot group with dependabot/feedback#123.

Could it support multiple PR #'s? i.e. @dependabot group with dependabot/feedback#123 dependabot/feedback#124 dependabot/feedback#125

[greysteil]

I don't see why not. I'm still totally 👍 on this one, but it's going to require quite a lot of work on my side (it interacts with rebasing, etc.).

[dwieeb]

Any way to follow progress on this? I'm subscribed to this issue, but do you use milestones or some form of public prioritization? 🙂

Just really excited for this 😄

[greysteil]

Subscribing to this issue is the way to go - I don't have a public (or private) prioritization at the moment, but will let you know if/when I do. Hopefully I'll get to this before that's necessary 🙂

[dmitry-timofeev]

Have not found the 11th issue for the option mentioned in the comment (it seems to be about completely different thing): https://github.com/dependabot/dependabot-core/issues/376#issuecomment-385011964

And would very likely lay the groundwork for dependabot/feedback#11: Option for single pull request per update

, this one seems the closest :-)

It would be very nice to have such an option for repositories that have long build times + requirement of up-to-date branches before merging into master. When each new dependency from the bot comes as a separate PR, a lot of builds start on the CI, and more later when some PRs are merged and other are updated to match the new master.

I understand why the default is a PR per dependency — if build fails, you know exactly why — but if most updates are minor or patch _and_ your deps follow semantic versioning I reckon it won't fail too frequently when all dependencies for a language are updated in a single PR. Major updates might still go in a separate PR as they are more likely to break the build.

[droanr]

+1

[lopezm1]

+1

[adriens]

That would also be great for Travis CI queuing 🙄

[bjeanes]

By way of comparison to Renovate, it has a way to define groups (e.g. React + ReactDOM) that should always be opened together (vs opening 2+ PRs, then manually grouping each time, then opening a 3rd PR, etc) and also ships with common groups.

I think for JS in particular, you could use peerDependency definitions to infer this, but for other languages it would still be nice to define groups.

https://renovatebot.com/docs/presets-monorepo/

[greysteil]

Sorry for the slow progress on this one. We've actually just implemented grouping based on peer dependencies (when a peer requirement would be broken).

Right now we're working on config files and want to get that shipped before picking anything else up, but once that's out this is really high up our list.

[ndelangen]

Awesome work @greysteil !

[nesl247]

If this could also be in the configuration file, or be a company wide setting, that would be awesome.

For example, we have a LOT of projects based on the Symfony framework. It's a modular framework, so we tend to have 5-15 dependencies that get updated once a week sometimes as they release patch versions. This is a PITA to approve when we have ~20ish projects that each have a lot of these dependencies to be merged in separately.

So having something like the ability to say: group all dependencies that match: symfony/*

[szpak]

I had been thinking about bumping different components of the same project (assuming the same version from and to - https://github.com/szpak/mockito-java8/pull/23 and https://github.com/szpak/mockito-java8/pull/24), but after I found this issue an ability to do manual bathing seems to be much easier to implement.

[RohanNagar]

Just chiming in on this - I would love to be able to group all dependency updates into one PR each week and be able to merge that. I realize this is a big feature but I'm looking forward to it!

[simlu]

Would love to see this as well! PRs are getting kind of noisy when you have a lot of fast changing deps.

[ThomasLemaire]

This is what we need too ! Thanks guys !

[misund]

Since I haven't seen it mentioned yet: Greenkeeper groups some popular monorepo dependencies. Here is their monorepo definition file, in case it could help you define a default grouping in javascript projects.

[greysteil]

Hey team,

Sorry for the slow progress on this one. I hear you all, and have seen all the 👍 reactions on the top-level issue!

Config files is shipped now, and in a state that we're happy with, so I've been picking up small robustness improvements throughout the codebase. I'm really keen to get to this soon, but want to make sure we do it right when we get to it.

The place we hear the most need for this, by far, is for JavaScript updates, where it's more common to split up packages than in other languages. As a result, when we get to this we'll start there.

The other use case we hear is "bundle all my updates together into a weekly PR". We don't hear that as often, so if a nice way to do it doesn't drop out of the solution to the above it may be a little longer before we support it. I can see how it might easily drop out, though.

[ErikSchierboom]

I also would really like this feature, as I have a C# project with many different projects, each of which has their own dependencies: https://github.com/exercism/csharp/

[merwok]

Both ideas would be really useful:

• config file or org settings to define upgrade groups (to reduce the volume of PRs and CI builds)
• a PR command to group two PRs in a one-off way (to fix an update problem or a difficult update)

[mario-paniccia]

This feature would be so important. For every PR we spin up infrastructure on the cloud where we test the PR against. So for us the one PR per version update is an overkill

[tapsboy]

I hope this feature is a top priority post acquisition. Renovatebot does this well.

[greysteil]

This is still a priority, but we have a lot on our plate right now, and our ethos has always been to focus on doing each thing well before moving on to the next. We're currently working to scale Dependabot up to work on 100m repos for security fixes, and ensure our language support is 💯.

That said, I'd really love this to be fully implemented before we integrate dependabot-preview fully into GitHub 🙂

[hngl]

@greysteil

The place we hear the most need for this, by far, is for JavaScript updates, where it's more common to split up packages than in other languages. As a result, when we get to this we'll start there.

This is common in other languages as well. For instance in PHP, the widely used Symfony framework consists of 20+ libraries which update in sync: symfony/serializer/, symfony/validator, etc.

Manually grouping PRs would be one solution. A better solution would be to inform Dependabot that the involved libraries should be updated together (if multiple updates availabe).

[michaelmior]

I think it would be preferable to be able to tell dependabot via a config file dependencies which should be updated together. Then if there's an outstanding PR for one of them, that PR would be updated if one of the other dependencies in the same group also has an update.

[jglick]

Note that this feature is typically unnecessary for Maven users, as you can simply introduce a POM property specifying the version of a set of dependencies from a common source, and the bot will correctly offer updates to this property. (More rarely, some projects offer a BOM for the convenience of clients.) There are however special cases where the author of a particular POM knows that a certain set of dependencies ought to be updated atomically despite not sharing a single version.

[michaelmior]

In my case, one specific example is for Storybook on node.js. There are several packages (@storybook/react, @storybook-addon-actions, etc.) which commonly have new releases issued together. Right now I have to merge each one, wait for dependabot to rebase, and so on. It would be great if all these could be issued as a single PR since I know the changes are related.

[greysteil]

That’s a really common use case @michaelmior - we have the same with gatsby on Dependabot’s own website, so I’m acutely aware of this one

[DaveOps83]

+1

[htor]

really would like to see this feature landing in soon, as it would reduce a lot of noise in our web projects using npm. often we do batch upgrades of all project deps upgrade using npm outdated and manually npm install <dep1@version> <dep2@version> ... - resulting in a single pull request. it would be beneficial to have dependabot mirror this behaviour, somehow!

[korelstar]

@htor You could use npm-upgrade (npm install -g npm-upgrade before) to simplify your workflow until this issue is fixed.

[papakai]

+1

[jeffutter]

I just wanted to say that I hope this can be resolved soon.

I use dependabot on a gatsby site with netlify. It ends up doing builds on Netlify for every PR. Netlify is going to start charging for build minutes in a couple of months with a free tier of 300 minutes. So far, this month on a couple of pretty trivial gatsby sites I've used 4,800 minutes of build, maybe 10-15 minutes of that have been from pushing features and the rest is all from dependabot PRs.

I realize this isn't directly a problem of dependabot but the workflow of gatsby + netlify + dependabot is _so nice_ it would be sad if I had to stop using it due to build costs from all of the PRs.

[eps1lon]

TL;DR: Use ignore_updates and only allow a single package of a group: https://github.com/mui-org/material-ui/blob/e89abcdd97d88862bb329dcf5774615112d27872/.dependabot/config.yml#L31-L41

We encountered this issue as well with @babel, react and jss packages. We now block any @babel PR and only allow react and jss updates. This preserves some of the benefit of being notified of an update with auto generated changelogs while not being spammed by separate PRs for react, react-dom and react-test-renderer which will always break separately.

[yaroslavmo]

This feature would be great. Rebasing each next PR is so annoying!

[michaelmior]

@eps1lon If I understand correctly, then you still have to go and update other related packages in a group manually? Personally, I take all the notifications to make sure I don't forget a package and then fix things up manually on my local machine.

[simlu]

@yaroslavmo @michaelmior Oh there are workarounds here. However none are super convenient. We, for example, set the maximum number of open PRs to one. That way at least we don't have to rebase.

We are also really, really looking forward to this feature!

[bwplotka]

Hi :wave: And thanks for the awesome project! A similar need is on our side, we use Go and our project has numerous deps.

We would love to be able to just set dependabot to do single PR in a given interval (e.g 3 or 6 weeks) with all deps upgraded and potential release notes. Reasons are similar to described here: Tons of rebasing and huge wait time if we would merge the dep upgrade PR one by one.

Is there any way we can help with this? (:

[jialin-wu-02]

This feature would be great. Looking forward to see it being implemented.

[michaelwclark]

This feature would save us quite a bit of manual coding in our monorepo tooling for consumers. Hope to see it soon!

[rebelagentm]

Supporting something like this is high on our list of enhancements. We hope to be able to get to this soon, once the team has the bandwidth.

[marco-c]

It'd be great each dependency update was a separate commit, but in a single PR. This would make bisecting easier.

[andreynering]

Another example is @babel/* dependencies, which are always released together, but today results in many PRs been open at once.

[DavG]

Same for symfony/* (php)

[mucsi96]

Using GitHub Actions it is not so hard to achieve. Here is an example for NodeJS project. https://github.com/w3c-webdriver/w3c-webdriver/pull/379/files
But should be very similar to other languages.

[domoritz]

@mucsi96 thanks for sharing. I still think a proper bot would be nice since it could support things like quickly exclude some dependencies, rebase a branch, and update when there is no user action for a week.

[BradErz]

Hi @rebelagentm sorry to ask Is it something that has been planned yet?

Im wondering if we have to start hacking around this or if it will be done some time soon. Currently we are basically using dependabot as a notification that some libaries have been released and should be updated. We then go in make our own branch run go get -u ./... and merge that pr.

[rebelagentm]

Hi, @BradErz! @feelepxyz could better answer on the status of this right now.

[feelepxyz]

@BradErz we've paused dependabot-core improvements while we focus on integrating Dependabot natively in GitHub, this is still at least a few months out, unfortunately.

[JaKXz]

@feelepxyz can you talk about whether this will be behind a paywall or not?

[feelepxyz]

@feelepxyz can you talk about whether this will be behind a paywall or not?

No current plans on charging for Dependabot or individual features.

[brianlovin]

we've paused dependabot-core improvements while we focus on integrating Dependabot natively in GitHub, this is still at least a few months out, unfortunately.

Thanks for the status update on this! I will be waiting on the sidelines for this, but just wanted to add a +1 that this feature would be great, and add one more additional reason: I use Vercel to automatically create deployments for every PR. On their free tier, you're allowed a certain number of deploys per day. On some days, if Dependabot bumps a ton of dependencies, it can quickly push me over my deployment limit and lock my account. This is an edge case, but does make me feel like (in my particular, low-stakes, side project) case, a "batch in-range dependency updates into a single PR" could be particularly useful (and eventually save me $$ on deploys).

Thanks team!

[sfdye]

@BradErz we've paused dependabot-core improvements while we focus on integrating Dependabot natively in GitHub, this is still at least a few months out, unfortunately.

Don't see any announcement in Satellite, but I am hoping it's getting close?

[stephanvierkant]

This would be great. It prevents PR's like this:

[feelepxyz]

We're planning on implementing this (it's our most requested feature) but this will come after we've launched the new integration of Dependabot native within GitHub (beta coming soon).

I'm locking this issue to prevent spamming existing subscribers.

[infin8x]

Duplicate of #1190

[wangyun1517]

We're planning on implementing this (it's our most requested feature) but this will come after we've launched the new integration of Dependabot native within GitHub (beta coming soon).

I'm locking this issue to prevent spamming existing subscribers.

@feelepxyz Any update on this?

[infin8x]

@wangyun1517 hoping to dig into this between now and the end of the year. If you'd like, head on over to #1190 to follow along.

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