Support batching of Pull Requests

[ianwremmel]

Similar to dependabot/feedback#5, but far more automated and far less intelligent.

I had to remove lock files from all of my projects because doing a live bump for every lockfile update lead my Circle CI usage to go from 4 hours a month to 60. I'd like to propose the following algorithm for batching PRs when anything other than live bumping is chosen:

1. On whatever schedule the user chooses, do the following:
2. open a PR with all updates.
3. if 1.1 fails, close the PR and open two PRs, one with half of the updates.
4. if 1.1 passes, stop

Merge or wait for user input as appropriate.

In general, this should reduce the number of runs for a given set of changes and, more importantly, when a PR gets merged, fewer CI runs should be triggered when ever dependency gets rebased independently.

[greysteil]

Thanks for the suggestion. The above sounds like a good approach to me.

The blocker on this is the same as on dependabot/feedback#5 - there's a bunch of work I need to get Dependabot to handle multi-commit PRs / PRs that update multiple dependencies. I'll definitely get to that, but have some work on monorepos and vendoring to do first.

[Hypnosphi]

Ideally, I would like a batch PR for in-range updates and a separate PR for each out-of-range update

[jglick]

I think this is more the responsibility of the CI system. For example, Prow/Tide runs an algorithm similar to this.

[ianwremmel]

While that’s a reasonable assertion in theory, I strongly disagree in practice. I’d bet the plurality, if not the majority of dependable users use circleci, Travis, or something similar; they’re relying on a third party with tooling that doesn’t and likely will never support batching. These services typically have monthly execution time limits. Dependabot’s current behavior can induce a one to two order of magnitude increase in CI consumption. Deploying a self-hosted ci system on kubernetes doesn’t seem like a reasonable suggestion.

[deiga]

@greysteil Would it be possible to assist in getting this feature done? We'd really love this feature for our projects and I'd be happy to look into implementing it if just pointed in the right direction :)

[terodox]

As a team that manages ~90 repos not having this feature is prompting us to move away from using dependabot. When an NPM vulnerability happens and we can get several PRs for a single repo. Having this happen across 90 repos is brutal. So at minimum a feature like grouping would allow us to avoid most of this pain.

[deiga]

@terodox Yeah, we've moved to using Renovate Bot, they have grouping and is so much configurable

[greysteil]

Sorry to see you go @deiga but that makes sense to me. We don't have the resource on Dependabot to work on this within GitHub whilst we scale up Dependabot's automated security fix PRs to work for everyone on GitHub. It's top of our feature list once that's done, though 🙂

[prantlf]

I agree with @terodox. It's easier to upgrade dependencies by a script once a month or quarter than plodding through dozens of pull requests made by depenadabot when an often-used npm module gets upgraded.

Dependabot could be made useful for most repositories if the upgrading request was configurable. Just once a month, for example. "Live, daily, weekly or monthly updates" says it on the home page, but there's only a checkbox to disable it in Github security settings.

Creating configuration files in each repository doesn't make this feature more appealing. Having a single configuration in Github settings would make it usable in many repositories maintained by people in their free time.

[merwok]

FWIW, the dependabot model works quite nicely for ecosystems like Python, with less dependencies per project and relative stability. The PRs let us see security updates immediately, read changelog entries, see CI results. I tend to do batch updates in a manual PR to avoid a ton of rebases, CI runs, merges, but getting that other information is valuable.

[prantlf]

Learning about security problems and updates that fix them as soon as possible is my desired goal. However, a notification would be enough. A flood of PRs to get rid of makes it more expensive. By the way, security alerts is already a feature of Github, which works perfectly.

@merwok, what you do makes sense. Upgrading all dependencies in one push. But why would you want to do it manually? Shouldn't the upgrades were batched by Dependabot for you?

If Dependabot maintained one PR and was adding modules to upgrade to the single PR, it would make the feature easy to use. The current effort of using Dependabot is as expensive as it was for Greenkeeper.

[merwok]

I don’t want to do it manually, it’s my current good-enough workaround to update dependencies in the lockfile until dependabot supports grouping or batching 🙂

[samdelacruz]

+1 for this. I've recently encountered problems with bumping interdependent npm package versions (aws-cdk being the main culprit) whereby all subpackages of aws-cdk must be updated simultaneously.

[DemoBytom]

Yeah, just got PRs from dependabot trying to update Microsoft packages, that cannot be upgraded separately, so builds just broke with error NU1605: Detected package downgrade:
Bundling them in single commit and/or a single PR would fix a lot of issues.

[mucsi96]

Until this feature is missing I wanted to share how I did batch dependency updates for npm in GitHub Actions. Solution should be very similar for other stacks. https://github.com/w3c-webdriver/w3c-webdriver/blob/master/.github/workflows/update-dependencies.yml

[AraHaan]

nice @mucsi96 happen to know of a way to create a github action that can bundle my dependency updates as well?

Although I need it to use something like this first though:

1 explicitly define the update chain like so:

Where it would bundle the updates to the Level 0 API (lowest levels of my apis) first, then wait till those packages are published to 1 of the feeds used on checking the updates, then go in work the way up the Levels of apis until the last level of it is done.

Sadly each of them for me are in separate github repositories and uses github actions where every direct push gets published to nuget. Going to work out the issue where branches made by dependabot or any sort of bot / action results in a publish before it opens the pr. It is probably a simple github action patch.

[infin8x]

Duplicate of #1190