Group updates across different ecosystems

[lorengordon]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

If I have a project using several package-ecosystem configurations, I would like to use the new groups feature to create a Dependabot PR that includes updates across multiple ecosystems. For example, I may be using Dependabot for docker, terraform, and pip. Currently, I have three separate groups, one for each eco-system, and so I get three separate PRs. Instead, I would like to get a single PR.

[abdulapopoola]

Thanks for raising this; the crew is starting to explore this. Tagging @honeyankit and @Nishnha

[deki]

This would be very useful. I have projects with multiple package ecosystem definitions per Maven POM and can't group them right now since #2178 isn't implemented.

[RolfMoleman]

This would be brilliant for us

[sethjeffery]

We have a private repo that publishes both a ruby gem and npm package, and would greatly benefit from grouping these together in dependabot PRs for other consuming repos, so that both can be updated at once.

[AArnott]

To use terminology that Dependabot itself uses for search engine optimization, what we want here is pull requests that can update a group of dependencies that span package managers.

[jeppester]

I guess the crew that started exploring this got lost somewhere...

I'm losing my hope that GitHub will improve as a service. There are so many smaller and larger problems that have gone unfixed for years.

[gmile]

Also interested in seeing support for this land. My use case is this: I have a repository with end-to-end tests written using Playwright. There are 2 components that need to be updated in a single PR:

1. playwright npm package,
2. playwright docker image

Today dependabot will open one PR for each, 2 PRs in total. Each PR is not passing the CI, because version of npm Playwright package must match version of Playwright inside docker image.

[robaiken]

I've started working on implementing this multi-ecosystem grouping feature for Dependabot!

Here's an example of what the configuration might look like:

version: 2
multi-ecosystem-groups:
  - name: "full-stack-dependencies"
    package-ecosystems:
      - ecosystem: "docker"
        patterns: ["node", "postgres"]
      - ecosystem: "terraform" 
        patterns: ["aws-*"]
      - ecosystem: "pip"
        patterns: ["*"]
       exclude-patterns: ["pandas"]
    labels: ["cross-ecosystem", "dependencies"]
    schedule:
      interval: "weekly"

This would create a single PR containing updates from docker, terraform, and pip ecosystems based on the specified patterns. The PR would be created weekly and automatically labeled. I think that having patterns per ecosystem will make the configuration more flexible, allowing you to precisely target which packages should be grouped together across different ecosystems.

Would this approach work for your use case? I'm collecting feedback before finalizing the implementation, so let me know if you have any thoughts on the configuration format or additional features that would be useful

[robaiken]

Hi everyone! Quick update on the multi-ecosystem grouping implementation. We're adding a new package-ecosystems array that allows grouping multiple ecosystems in a single PR:

updates:
  - package-ecosystems:
    - package-ecosystem: "docker"
      patterns: ["node*"]
      directory: "/docker"
    - package-ecosystem: "npm"
      patterns: ["*"]
      directory: "/app"
    schedule:
      interval: "weekly"
    labels: ["cross-ecosystem"]

Key points:

• Alternative to single package-ecosystem field
• Pattern is required for each ecosystem in the array
• Supports all existing configuration flags
• Creates single PRs for related updates across ecosystems
• You can use either package-ecosystem OR package-ecosystems (not both).

Would appreciate any feedback on this approach!

[AArnott]

I'm a big confused then. How can we control which dependencies get grouped together? Can multiple package-ecosystems objects be specified in order to define the sets?

e.g. How would I express that I want a cross-ecosystem update PR for .NET SDK, but other updates should be individual?

updates:
  # update Dockerfile and global.json reference to .NET SDK version together
  - package-ecosystems:
    - package-ecosystem: "docker"
      patterns: ["mcr.microsoft.com/dotnet/sdk"]
      directory: "/.devcontainer"
    - package-ecosystem: "globalJson" # what would I put here to update global.json's SDK reference?
      patterns: ["sdk"]
      directory: "/"
    schedule:
      interval: "weekly"
    labels: ["dotnet-sdk"]

  # Update package that appears in global.json as an msbuild-sdk as well as in Directory.Packages.props as a package reference
  - package-ecosystems:
    - package-ecosystem: "globalJson"
      patterns: ["MicroBuild.Sdk"]
      directory: "/"
    - package-ecosystem: nuget
      patterns: ["MicroBuild.Sdk"]
      directory: /

  - package-ecosystems:
     # everything else, keep individual rather than grouping as a single PR

[dekimsey]

Hi everyone! Quick update on the multi-ecosystem grouping implementation. We're adding a new package-ecosystems array that allows grouping multiple ecosystems in a single PR

Thank you for the update! Would this enable us to have one set of configuration on a frequent cadence (daily) and then a separate set of updates for another?

In effect allow one to say, "I want security updates daily, and then regular version-updates monthly" for the same (package-ecosystem, directory, and target-branch). This is currently impossible, but this change suggests it may be possible.

[robaiken]

@dekimsey thanks for the question! Security updates don't run on a schedule, they get created right away when vulnerabilities are found, no matter if you've got daily, weekly, or monthly schedules for your regular updates. So you've already got that separation between security and regular updates since security ones don't wait around for your schedule.

You can also use applies-to: security-updates in your grouping config to control how security updates get grouped, and we're planning to make this work with multi-ecosystem updates too.

Here is more information about security updates

[dekimsey]

@dekimsey thanks for the question! Security updates don't run on a schedule, they get created right away when vulnerabilities are found, no matter if you've got daily, weekly, or monthly schedules for your regular updates. So you've already got that separation between security and regular updates since security ones don't wait around for your schedule.

Hrm, I'll need to do some digging then. We definitely aren't seeing pull requests get opened when we have code scan findings. Perhaps our existing configuration is incorrect or conflicting. Something for us to look into is more detail!

Regardless, this is solidly off-topic now 😅. Thank you for the information and the pointers, it gives me a thread to pull!