Dependabot-core: Improvement Proposal: Configurable Pull Requests

Created on 24 Oct 2020 · 6Comments · Source: dependabot/dependabot-core

Summary

Dependabot provides several pull requests all for the same repository. These diffs in the repository are pretty trivial and generally involve changes only relating to package managers. Pull Requests needs to be configurable from a dependabot.yml file.

Implementation

Commit Structure

Currently, commits are structured for only a single version change.

@dependabot
Bump elliptic from 6.5.0 to 6.5.3 …
00dff40
Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.0 to 6.5.3.
- [Release notes](https://github.com/indutny/elliptic/releases)
- [Commits](indutny/[email protected])

Instead, add all changes to a single commit and have it structured something like this.

@dependabot - Version Updates

Bump elliptic from 6.5.0 to 6.5.3 … 00dff40
Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.0 to 6.5.3.
- [Release notes](https://github.com/indutny/elliptic/releases)
- [Commits](indutny/[email protected])

Bump lodash from 4.17.15 to 4.17.20 ... 0e4a060
Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.20.
- [Release notes](https://github.com/lodash/lodash/releases)
- [Commits](lodash/[email protected])

Configuration with `dependabot.yml`

For complete and full granular control of how @dependabot configures pull requests. A dependabot.yml file seems most ideal.

Example Configuration:

ignore:
  - list
  - packages
  - here

group:
  - list
  - packages
  - here

group:
  - multiple
  - iterations

Example Configuration Group All:

group:
  - *

Example Configuration Grouping Based on organization deps:

group
  - @org/*

`ignore`

The ignore key in the .yml file ignores all the packages

`group`

The group key in the .yml file groups all packages into the same pr.

Both keys can be iterated multiple times in the .yml file.

Project Structure

If the project is running on a monorepo. You can have multiple .yml files in each respective folder. @dependabot will walk through each folder to find the .yml file.

feature-request

Source

ChrisCates

👍7

Most helpful comment

This might be useful as a real world example, we had similar issues using a custom variant of the Dependabot script with our self-hosted gitlab server, developers complained about the number of Merge Requests that where being generated. To fix this we extended the dependabot configuration with group_updates which has similar traits with ignored_updates and allowed_updates, where by you state package names that should be grouped.

version: 1
update_configs:
  - package_manager: dotnet:nuget
    directory: /Source
    update_schedule: daily
    ...
    group_updates:
      - match:
          dependency_name:*

The result of including all packages into a single, so not only do the developers get bothered less with merge messages, the number of auto-merge fails due to conflicts requiring a rebase has been almost reduced to zero.
Grouped Packages Updates

Jacob-Morgan on 30 Oct 2020

👍4 ❤2

All 6 comments

I would prefer to list not only individual packages, but to also have the ability to list entire organizations.
For example, organizations like @types or @symfony could be good candidates for an organization-wide grouping.
Please see https://github.com/dependabot/dependabot-core/issues/1190#issuecomment-718919532 for further details.

Listing individual packages is fine in some cases, but there are also cases where an organization-wide grouping is easier to maintain than individual packages.

For example, I have multiple dependencies of the @capacitor organization: https://capacitorjs.com/
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.

fkirc on 29 Oct 2020

👍1

@fkirc, would love to be able to do something like this.

group:
  - @symfony/*
  - @laravel/*
...

I agree with that!

ChrisCates on 29 Oct 2020

👍3

version: 1
update_configs:
  - package_manager: dotnet:nuget
    directory: /Source
    update_schedule: daily
    ...
    group_updates:
      - match:
          dependency_name:*

Jacob-Morgan on 30 Oct 2020

👍4 ❤2

I have a monorepo and even though it is not very large at the moment I expect the sheer volume of PR's will be difficult to handle as the repo grows. I'd love to be able to configure dependabot like this. Great idea!

@fkirc, would love to be able to do something like this.
group:
  - @symfony/*
  - @laravel/*
...
I agree with that!

That looks like a good idea for handling grouped dependencies, @ChrisCates why not update your proposal with these examples?

h-no on 2 Nov 2020

@Jacob-Morgan, thanks for the reference to that fork! Very important.

@h-no, agreed, going to add that!

I still feel the structure of this IP needs to be sorted out.
But this is a rough draft so to speak and just something to use as a reference.

ChrisCates on 2 Nov 2020

I am currently looking at the adoption of dependabot for the Kubeflow project, and as many others the amount of PRs that will be created for a given repository (and the resulting load on the AWS testing infra) are the man reasons for concern. The ability to group dependency updates together seems to be the most effective way to combat this issue, along with the problem that some dependencies need to be updated together to be functional. To me it seems the solution provided in https://github.com/dependabot/dependabot-core/issues/2672#issuecomment-719130140 is a good way forwards. What would be required to start getting this integrated into dependabot?