Dependabot-core: Option for single pull request per update

[greysteil]

_From @zach-taylor on June 20, 2017 18:37_

We use deppbot (https://www.deppbot.com) at the moment and we like the idea of a single pull request for each update rather than a pull request for each gem update. The main reason we like this is we have a lot of dependencies, and it can get noisy and slow to perform a build for each one and the way our branch protections are set up.

Thanks for the consideration!

_Copied from original issue: dependabot/feedback#11_

[greysteil]

Thanks Zach. We might add a setting for this at some point, but it's not on our roadmap right now - we prefer the multiple PRs approach as it makes them easier to test and merge. That said, we can see a world where we open a single PR for several dependency updates we know are backwards compatible.

In the meantime, Deppbot are the guys to use if you want a single PR with many Ruby updates in it.

[greysteil]

_From @zach-taylor on June 21, 2017 18:55_

Sounds good 👍 I figured I would put it out there and explain our reasoning.

[greysteil]

Quick update: we'd still love to do this (group non-breaking updates), but it's going to need us to have lots of data to do it well (we need to know which changes are breaking). One for the future - don't worry, it won't fall off our roadmap.

[greysteil]

_From @ad-m on October 1, 2017 12:19_

In my opinion it is not a problem that many changes will be under one pull request. Many CIs test each commit separately, so you can continue to accurately identify the defective dependency.

[greysteil]

_From @elamperti on November 5, 2017 2:32_

+1 to this request. Having a weekly/monthly update of all my npm packages would allow me to check quickly if they break something. If that's the case, I can analyze it and fix it manually, but otherwise it's faster than the time and resource consuming alternative of bumping versions for each package. I want to focus on the code, not on updates, and one PR per package creates a lot of noise -at least in my small repos-.

[greysteil]

_From @shusson on November 20, 2017 5:59_

@greysteil any news on this? I would like to be able to bump with one PR, if it breaks, bump with multiple PRs. The hope being that the original PR doesn't break often and thus we get the best of both flows.

[greysteil]

We're still a way off, but should get closer in the next few weeks. Basically, I need to do a lot of refactoring because everywhere in the update process it expects to be dealing with a single dependency. I should be able to get to that pretty soon, and this isn't the only thing waiting on it. Once that's done, the changes to make this possible are a lot more straightforward.

In the meantime, I continue to recommend Deppbot if you want a single PR with many Ruby updates in it 🙂 .

[greysteil]

_From @styfle on December 9, 2017 17:1_

This was pretty painful for my Electron project to build the PR and then build the build master after merging. https://github.com/styfle/magnemite

I think the big problem is that after accepting 1 PR, all the other PRs need to be rebased and rebuilt again. So for 6 deps that need to be updated, you have to wait for 21 builds to complete. At 5 minutes per build, thats almost 2 hours. And you are spending that time clicking waiting and watching CI so you can click Merge on the next PR.

I did fix a bug with travis-ci that was building the PR twice, once for the branch and once for the PR. But this is the default behavior so I'm probably not the only one with that configuration.

[mikeckennedy]

+1 for this feature. I would much prefer a single PR per week to group all the updates. It's easy enough to diagnose this manually if something is wrong. Why make the case that works 99% of time harder? I could always be a config option off by default.

[DavG]

+1
At least add some rules to "group" updates.
We use symfony framework and (almost) all packages versions are synchronized.
It's useless and weird having updates and seperated PR :

I just had the case : dependabot updated a symfony package to 4.2.12 and updated another package to 4.3.9. Not logical in that case.

[flavioribeiro]

+1

[samhwang]

+1

This would be a very nice addition to dependabot's arsenal.

[markcellus]

@greysteil my team is looking for grouping of PRs of the _same_ dependency. Often times we may leave a dependabot PR sitting because we need to do some investigation and we'll leave comments on the PR. But a newer version of the dependency comes out which makes dependabot close the original PR losing all of our comments. Is this related to this issue or should a new one be created?

[greysteil]

I don't work on Dependabot anymore, but @feelepxyz and the team may be able to help.

[feelepxyz]

my team is looking for grouping of PRs of the _same_ dependency. Often times we may leave a dependabot PR sitting because we need to do some investigation and we'll leave comments on the PR. But a newer version of the dependency comes out which makes dependabot close the original PR losing all of our comments. Is this related to this issue or should a new one be created?

This could probably be achieved if we support configurable grouping. Currently, we open a new PR for every update because we rely on things like the branch name to be unique per version update and this would no longer apply once we start updating an existing PR with newer versions.

Support for grouping updates is high up our list: https://github.com/dependabot/feedback/issues/5

We're currently busy integrating Dependabot natively in GitHub so we've paused on feature work for the next few months while we complete this work.

[Br4nd0R]

+1 for this feature

[drtyh2o]

Would be super cool dependabot would group updated dependencies from the same scope into a single PR. Often, these scoped packages are published as a set and need to be updated as such.

[CarlosHAraujo]

+1