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.

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

[tomkerkhove]

This is an example of why this feature is important:

In .NET world, this will never work given they all need to be updated simultaneously.

[dave-yotta]

Yeah this needs to be much more configurable. E.g. doesn't make sense to test updating MongoDB.Driver on 1/10 csproj without updating any other MongoDB.* pacakges within the same PR - it will simply fail to build.

[nbarbettini]

updating MongoDB.Driver on 1/10 csproj without updating any other MongoDB.* pacakges within the same PR - it will simply fail to build

This is the reason I want grouped updates too -- packages that depend on each other that need to be updated at once. As it stands, one PR per package will fail like you said.

[LeviPesin]

Same reason for me as well.

[nwalters512]

The lack of grouped updates means that we end up using a huge number of Actions minutes every time we merge a Dependabot PR due to all the other PRs being rebased. The resulting queue of jobs means that our repo is essentially frozen for hours as we wait for the queue to clear. If others are facing this same problem, you can disable rebasing by adding rebase-strategy: disabled to your config file: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#rebase-strategy.

[jeffwidman]

A gentle reminder of what I said previously:

Unlocking by request so that folks can upvote this as a feature request.

Feel free to leave comments that meaningfully add to the conversation, but avoid comments like "bump" or "we need this" or "is there an update / ETA?" as they waste everyone else's time.

At this time there is no ETA, but I will say we are fully aware this is a high-value feature, and although it could be quarters or years away, I do expect we will ship some sort of grouped update functionality at some point. Subscribe to this issue to get notified whenever that eventually happens.

The last eight comments on this ticket are effectively spam for everyone else who's subscribed to this ticket for updates... if this continues, I'll have to lock the issue again.

[nilekhc]

Unlocking by request so that folks can upvote this as a feature request.

Feel free to leave comments that meaningfully add to the conversation, but avoid comments like "bump" or "we need this" or "is there an update / ETA?" as they waste everyone else's time.

At this time there is no ETA, but I will say we are fully aware this is a high-value feature, and although it could be quarters or years away, I do expect we will ship some sort of grouped update functionality at some point. Subscribe to this issue to get notified whenever that eventually happens.

@jeffwidman Let me know if I can help with testing if the feature is in works

[dave-yotta]

I think the strategy is not straight-forward. Grouping everything in one PR would help, since the PR can be edited to revert some of the updates to get a partial set.

However configuration or UI to expiate this would really help e.g.

updateGroups:
   group1:
     - MongoDb*
     - System.Bson*
     - Stackexchange.Redis*
   group2:
     - Microsoft.CodeAnalysis*
   group3:
     - *

so that there are 3 potential PRs that could be opened at any one time.

Not sure if you can use the package dependencies to automatically form default "groups".

[brcarp]

However configuration or UI to expiate this would really help e.g.

updateGroups:
   group1:
     - MongoDb*
     - System.Bson*
     - Stackexchange.Redis*
   group2:
     - Microsoft.CodeAnalysis*
   group3:
     - *

@dave-yotta with YAML you can have nested/multidimensional arrays without having to name them, which would make maintaining such a configuration easier. For example:

updateGroups:
  -
    - MongoDb*
    - System.Bson*
    - Stackexchange.Redis*
  - 
    - Microsoft.CodeAnalysis*
  -
    - *

[dave-yotta]

I'm just giving some gist...but I think named groups would be nice to see e.g. on the PR title. Maybe the model gets deeper as there are other things possibly relevant such groups forward-looking:

updateGroups:
 - name: Databases
   frequency: .... other stuff
   patterns:
    - MongoDb*
.....

etc...

[levrik]

@brcarp But also quite unreadable IMO. I think named groups would be better.

[bajtos]

In the past, I had good experience with Renovate bot. Their configuration format is a bit complex, but also very versatile. Maybe we can draw some inspiration from there?

Documentation: https://docs.renovatebot.com/configuration-options/#packagerules

Here is an example if you want to group together all packages starting with eslint into a single branch/PR:

{
  "packageRules": [
    {
      "matchPackagePatterns": ["^eslint"],
      "groupName": "eslint packages"
    }
  ]
}

[PovilasKM]

Hi, we are currently in a similar situation as bajtos above. Due to company reasons, we are moving from renovatebot to dependabot and we really miss the ability to group pull requests by scope in the same repository.

For example, instead of having 5 pull requests that update patch versions of 5 different dependencies, causing builds for every PR and rebuilds after every merge, renovatebot was able to group them all into a single PR. In this case, we except patch versions to not break anything so we are much more lenient on testing them.
This would make dependabot much easier to use and wouldn't strain our pipeline as much.

[simonhaenisch]

At least a simple option to group all minor and patch updates into the same PR would be very helpful already.

[jeffwidman]

I'm going to lock this for now to spare the inboxes of folks who are subscribed primarily for updates.

[abdulapopoola]

The team is actively working on grouped updates this quarter - see the public GU roadmap issue. We plan to engage regularly to carry everyone along.

[carogalvin]

👋🏻 Hey everyone, I'm the Product Manager for Dependabot Updates. If you would be interested in providing your feedback on Dependabot and answer a bunch of questions about how you use it today, please feel free to book a time on my calendar: https://calendar.app.google/LSmEJHaWB8wNU16D9

In particular, we are currently researching how Security Updates should behave for grouping, and recruiting for the private beta of grouped Version Updates in May. Please feel free to book a slot or email me at carogalvin[at]github.com if you're interested!

[carogalvin]

GREAT NEWS! In case you haven't seen it already, grouping rules for version updates is now in PUBLIC BETA which means you will be able to set up grouping rules for any repo now!

Since we are in public beta, you may notice some instability or changes in behaviour without notice. If you encounter any bugs, please file new issues for them and the team will take a look.

You can see the docs on how to set these up here: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups

We'll be leaving this issue open until we exit public beta.

If you have any feedback, please feel free to email me at [email protected] or set up a meeting with me by picking a convenient time in my calendar here.

[jurre]

We're working on adding support for grouping on SemVer levels, some details here which links to a form you can fill out for private beta access for the feature

[carogalvin]

FYI for anybody using groups, we discovered this bug that may result in you seeing multiple grouped and ungrouped PRs for the same updates. We're working on a fix now, and you can track the linked issue for updates.

[carogalvin]

Good news! Grouped updates for Dependabot version updates is officially generally available 🥳

Read our blog post here: https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-with-dependabot/
See the docs here: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups

With that, we will close this issue. Thanks everyone for your feedback!