🚀 Beta Release: Multi-Ecosystem Updates

[robaiken]

We're excited to announce the beta release of multi-ecosystem updates for Dependabot! This feature allows you to create groups that span multiple package ecosystems and get a single PR with updates across all supported ecosystems.

How It Works

Instead of receiving separate PRs for each ecosystem (docker, terraform, pip, etc.), you can now configure groups that consolidate updates into a single PR per group.

Example Configuration

version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
  
  full-stack:
    schedule:
      interval: "daily"

updates:
  - package-ecosystem: "docker"
    directory: "/"
    multi-ecosystem-group: "infrastructure"
  
  - package-ecosystem: "terraform"
    directory: "/"
    multi-ecosystem-group: "infrastructure"
    
  - package-ecosystem: "pip"
    directory: "/"
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "npm"
    directory: "/frontend"
    multi-ecosystem-group: "full-stack"
    
  - package-ecosystem: "bundler"
    directory: "/backend"
    multi-ecosystem-group: "full-stack"

Use Cases

• Infrastructure projects: Group docker, terraform, and configuration management updates
• Full-stack applications: Coordinate frontend and backend dependency updates
• Cross-platform libraries: Keep the same library versions aligned across different ecosystems
• Microservices: Group related services that should be updated together

Getting Started

1. Add multi-ecosystem-groups to your .github/dependabot.yml
2. Define your groups with scheduling preferences
3. Assign ecosystems to groups using multi-ecosystem-group
4. Commit and watch for consolidated PRs!

Known Issues

YAML Schema Validation: You may see red underlines in your config file. This is expected as we haven't updated the schema validation rules yet. The configuration will still work correctly.

We Want Your Feedback!

This is a beta release, and we'd love to hear about your experience:

• What use cases are you trying to solve?
• How well does the grouping work for your projects?
• Any issues or unexpected behavior?
• Feature requests for future improvements?

Please share your thoughts, configurations, and experiences in the comments below. Your feedback will help us improve this feature before general availability.

Related Issues

• Original feature request: Group updates across different ecosystems #8126
• Documentation updates: Coming soon

Thanks for being part of the beta! 🙏

[broksonic21]

Fantastic! Can you give an example where you want just one package always grouped, but not others, in terms of configuration.

As an example, say:

• NPM and Bundler to be separate groups
• But playwright (NPM) and playwright-ruby-client (Bundler) to be grouped together as they should be updated in sync

Thanks!

[robaiken]

@broksonic21 Absolutely! This is a great use case for the patterns feature. You can have most packages stay separate while grouping only specific related packages together:

version: 2

multi-ecosystem-groups:
  playwright-sync:
    schedule:
      interval: "weekly"

updates:
  # Regular NPM updates (excluding playwright)
  - package-ecosystem: "npm"
    directory: "/"
    ignore:
      - dependency-name: "playwright"

  # Regular Bundler updates (excluding playwright-ruby-client)  
  - package-ecosystem: "bundler"
    directory: "/"
    ignore:
      - dependency-name: "playwright-ruby-client"

  # Playwright packages grouped together across ecosystems
  - package-ecosystem: "npm"
    directory: "/"
    patterns: ["playwright"]
    multi-ecosystem-group: "playwright-sync"

  - package-ecosystem: "bundler" 
    directory: "/"
    patterns: ["playwright-ruby-client"]
    multi-ecosystem-group: "playwright-sync"

This configuration will give you:

• Separate PRs for all other NPM and Bundler updates
• One consolidated PR whenever playwright or playwright-ruby-client need updates, ensuring they stay in sync

The key is using patterns to target specific packages for grouping while using ignore on the regular ecosystem updates to exclude those same packages from separate PRs.

Documentation links:

• Dependabot configuration options
• Controlling which dependencies are updated
• Configuring Dependabot version updates

[kyle-leonhard]

@robaiken - heads up, configuration similar to the example produces an error: The property '#/updates/0/patterns' is required when 'multi-ecosystem-group' is set. But setting patterns produces: The property '#/updates/0/' contains additional properties ["patterns", "multi-ecosystem-group"] outside of the schema when none are allowed

[robaiken]

@kyle-leonhard sorry for the delay! It looks like Docker doesn't have any available updates, which prevents us from creating an update. We only group ecosystems together when all of them have updates available. If you remove Docker from the config (and possibly Cargo too if it has no updates), you should start getting your bump pull requests

[kyle-leonhard]

@kyle-leonhard sorry for the delay! It looks like Docker doesn't have any available updates, which prevents us from creating an update. We only group ecosystems together when all of them have updates available. If you remove Docker from the config (and possibly Cargo too if it has no updates), you should start getting your bump pull requests

Thanks for the reply, @robaiken . Oh! My two cents - that behaviour is unexpected, surprising. I'd expected all available updates to be created, even if some ecosystems don't have available updates, a very common occurrence in my experience.

Is that behavior something you've considered changing?

[MatMoore]

I think I've run into the same issue. My expectation was the same as @kyle-leonhard - I thought that dependabot would create the update PR at the first opportunity, and then later on it might add updates from the other ecosystem to the PR.

Not creating a PR straight away makes sense if you are filtering with patterns and you know that every update to one ecosystem implies a corresponding update will land in the other ecosystem, but I didn't get that sense from the feature description or the infrastructure/full-stack example.

I'm also finding it a little bit hard to debug what's going on when testing this feature. If the updates array in my yaml contains multiple items per ecosystem (as in this example) then I end up with multiple entries on the /network/updates page for the same ecosystem, with no obvious way to distinguish them.

In case it is helpful, here is the configuration I tried. What I was trying to test was

• 1 multi ecosystem group that covers a specific pair of dependencies
• Certain other things are grouped together within ecosystems
• Everything else is a single PR

When the npm dependency was updated within the multi ecosystem group, I had the same result as @kyle-leonhard: the branch was created, I see a "Dependabot ran into an issue when attempting to create the pull request" error, and the logs show the job as successful.

[kyle-leonhard]

@robaiken what do you think? Is this behavior something you'd consider adjusting? Otherwise, for my purposes, the feature is unusable.

[robaiken]

@kyle-leonhard @MatMoore I need to correct my previous response - we've actually reversed this decision after further discussion with the team.

Multi-ecosystem groups will now create pull requests even when only a subset of the configured ecosystems have available updates. The group will include whichever ecosystems have updates available at the time, so you should start seeing your bump pull requests even if some ecosystems don't have updates.

Thanks for your patience while we worked through this behavior!

[AppSecCharlie]

Very cool! Can we also use the applies-to and dependency-type keys? e.g. if I wanted one group for all security updates (applies-to: security-updates, and one for all prod updates (dependency-type: production).. how might that be configured?

When I try the config below, getting errors:

The property '#/updates/0/' contains additional properties ["applies-to"] outside of the schema when none are allowed
The property '#/updates/1/' contains additional properties ["dependency-type"] outside of the schema when none are allowed
The property '#/updates/2/' contains additional properties ["dependency-type"] outside of the schema when none are allowed

Sample config (I'd like to also include npm updates in the prod/dev/security groups, but keeping it simple for now):

version: 2

multi-ecosystem-groups:
  prod:
    schedule:
      interval: "monthly"
  dev:
    schedule:
      interval: "monthly"
  security:
    schedule:
      interval: "weekly"
    
updates:
  - package-ecosystem: "pip"
    directories:
      - "**/*"
    multi-ecosystem-group: "security"
    applies-to: "security-updates"
    patterns:
      - "*"

  - package-ecosystem: "pip"
    directories:
      - "**/*"
    multi-ecosystem-group: "prod"
    dependency-type: "production"
    patterns:
      - "*"

  - package-ecosystem: "pip"
    directories:
      - "**/*"
    multi-ecosystem-group: "dev"
    dependency-type: "development"
    patterns:
      - "*"

[parkerbxyz]

Does it work if you put applies-to and dependency-type keys under groups?

version: 2

multi-ecosystem-groups:
  prod:
    schedule:
      interval: "monthly"
  dev:
    schedule:
      interval: "monthly"
  security:
    schedule:
      interval: "weekly"
    
updates:
  - package-ecosystem: "pip"
    directories: ["**/*"]
    patterns: ["*"]
    multi-ecosystem-group: "security"
    groups:
      security-updates:
        applies-to: "security-updates"

  - package-ecosystem: "pip"
    directories: ["**/*"]
    patterns: ["*"]
    multi-ecosystem-group: "prod"
    groups:
      prod-deps:
        dependency-type: "production"
      
  - package-ecosystem: "pip"
    directories: ["**/*"]
    patterns: ["*"]
    multi-ecosystem-group: "dev"
    groups:
      dev-deps:
        dependency-type: "development"

[AppSecCharlie]

@parkerbxyz closer.. I ended up having to do patterns: - "*" in a few places to make Dependabot's YAML parser happy. Currently using something like this, but it seems to lump everything together in the security group (e.g. I'm getting updates that should be in the prod or dev group all just going to the security group):

version: 2

multi-ecosystem-groups:
  prod:
    schedule:
      interval: "monthly"
  dev:
    schedule:
      interval: "monthly"
  security:
    schedule:
      interval: "weekly"

updates:
  - package-ecosystem: "pip"
    directories:
      - "**/*"
    multi-ecosystem-group: "security"
    patterns:
      - "*"
    groups:
      python-security:
        applies-to: "security-updates"
        patterns:
          - "*"

  - package-ecosystem: "pip"
    directories:
      - "**/*"
    multi-ecosystem-group: "prod"
    patterns:
      - "*"
    groups:
      python-prod:
        dependency-type: "production"

  - package-ecosystem: "pip"
    directories:
      - "**/*"
    multi-ecosystem-group: "dev"
    patterns:
      - "*"
    groups:
      python-dev:
        dependency-type: "development"

[AppSecCharlie]

If I use your version I get an error:

Dependabot encountered the following error when parsing your .github/dependabot.yml:

The property '#/updates/0/groups/python-security' of type object did not match one or more of the required schemas

...which is why I also have patterns: ["*"] for the python-security group, not just for the security multi-ecosystem-group

[nashafa]

I tried something like this for just dependency-type with a project using pip and npm, but it seems to be ignored and all updates to both production and development dependencies fall into the last ecosystem group in a single PR.

I also tried using allow to specify dependency-type and this behavior seems broken. Dependabot did create a PR with only production dependencies, but then it also created a second PR including both production and development dependencies without closing the first.

[mihkeleidast]

Any info on GHES availability?

[robaiken]

@mihkeleidast We're planning to include this feature in the upcoming GHES version

[mihkeleidast]

So 3.18? Or later?

[robaiken]

I just checked the release schedule for GHES and it's probably going to be 3.19

[mihkeleidast]

Alright, thanks!