From baae69c4685f0b1efdcd0ee2c7a4dd1d86eb39b5 Mon Sep 17 00:00:00 2001 From: Copilot <198982749+Copilot@users.noreply.github.com> Date: Thu, 12 Mar 2026 17:30:37 -0700 Subject: [PATCH 1/3] =?UTF-8?q?Enable=20projects-v2-timeline-events=20for?= =?UTF-8?q?=20GHES=20=E2=89=A53.19,=20remove=20public=20preview=20note=20(?= =?UTF-8?q?#60202)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: skw <113158+skw@users.noreply.github.com> --- .../adding-items-to-your-project.md | 3 --- data/features/projects-v2-timeline-events.yml | 1 + 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/content/issues/planning-and-tracking-with-projects/managing-items-in-your-project/adding-items-to-your-project.md b/content/issues/planning-and-tracking-with-projects/managing-items-in-your-project/adding-items-to-your-project.md index 564545364bf4..9446b61d2bc1 100644 --- a/content/issues/planning-and-tracking-with-projects/managing-items-in-your-project/adding-items-to-your-project.md +++ b/content/issues/planning-and-tracking-with-projects/managing-items-in-your-project/adding-items-to-your-project.md @@ -19,9 +19,6 @@ You have several options for adding issues and pull requests to your project. Yo {% ifversion projects-v2-timeline-events %} -> [!NOTE] -> Timeline events for Projects is currently in {% data variables.release-phases.public_preview %} and subject to change. - When you add an issue or pull request to your project, an event will be added to the issue or pull request's timeline. Timeline events will also be added when you remove issues or pull requests and when changes are made to its `status` field for those items. Timeline events are only visible to people who have at least read permission for the project. If a change is made by a built-in workflow, the activity will be attributed to **@github-project-automation**. {% endif %} diff --git a/data/features/projects-v2-timeline-events.yml b/data/features/projects-v2-timeline-events.yml index ead0b430e491..7f6ef27a10f2 100644 --- a/data/features/projects-v2-timeline-events.yml +++ b/data/features/projects-v2-timeline-events.yml @@ -3,3 +3,4 @@ versions: fpt: '*' ghec: '*' + ghes: '>=3.19' From e838e2fd3366e294f18589fe22dbbac342316872 Mon Sep 17 00:00:00 2001 From: Vanessa Date: Fri, 13 Mar 2026 11:02:08 +1000 Subject: [PATCH 2/3] Remove 3.19.2 release notes reference (#60204) --- data/release-notes/enterprise-server/3-19/2.yml | 2 -- 1 file changed, 2 deletions(-) diff --git a/data/release-notes/enterprise-server/3-19/2.yml b/data/release-notes/enterprise-server/3-19/2.yml index 84ad7d1ec51a..3daef123466d 100644 --- a/data/release-notes/enterprise-server/3-19/2.yml +++ b/data/release-notes/enterprise-server/3-19/2.yml @@ -94,8 +94,6 @@ sections: The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | Upgrading or hotpatching to 3.19.1 may fail on nodes that have been continuously upgraded from versions older than 2021 (i.e. 2.17). If this issue occurs, you will see log entries prefixed with `invalid secret` in ghe-config.log. If you are running nodes from these older versions, it is recommended not to upgrade to 3.19.1. - - | - Release Notes update issue -- https://github.com/github/docs-content/issues/20792 - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | From 4183bf1f5e40d45d09bef365334ea8f86d0dc55b Mon Sep 17 00:00:00 2001 From: mc <42146119+mchammer01@users.noreply.github.com> Date: Fri, 13 Mar 2026 12:03:21 +0000 Subject: [PATCH 3/3] [EDI] Configuring multi-ecosystem updates for Dependabot (#60101) Co-authored-by: Sam Browning <106113886+sabrowning1@users.noreply.github.com> --- .../concepts/supply-chain-security/index.md | 1 + .../multi-ecosystem-updates.md | 163 +++++++ .../configuring-multi-ecosystem-updates.md | 118 +++++ .../secure-your-dependencies/index.md | 1 + .../dependabot-options-reference.md | 2 +- .../configuring-multi-ecosystem-updates.md | 407 ------------------ .../secure-your-dependencies/index.md | 2 +- .../dependabot-multi-ecosystem-support.yml | 6 + 8 files changed, 291 insertions(+), 409 deletions(-) create mode 100644 content/code-security/concepts/supply-chain-security/multi-ecosystem-updates.md create mode 100644 content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates.md delete mode 100644 content/code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates.md create mode 100644 data/features/dependabot-multi-ecosystem-support.yml diff --git a/content/code-security/concepts/supply-chain-security/index.md b/content/code-security/concepts/supply-chain-security/index.md index 3b9f3424ff7a..bc1192622400 100644 --- a/content/code-security/concepts/supply-chain-security/index.md +++ b/content/code-security/concepts/supply-chain-security/index.md @@ -19,6 +19,7 @@ children: - about-dependabot-security-updates - about-dependabot-version-updates - about-dependabot-pull-requests + - multi-ecosystem-updates - about-the-dependabot-yml-file - about-dependabot-auto-triage-rules - about-dependabot-on-github-actions-runners diff --git a/content/code-security/concepts/supply-chain-security/multi-ecosystem-updates.md b/content/code-security/concepts/supply-chain-security/multi-ecosystem-updates.md new file mode 100644 index 000000000000..d60dcce19afa --- /dev/null +++ b/content/code-security/concepts/supply-chain-security/multi-ecosystem-updates.md @@ -0,0 +1,163 @@ +--- +title: Multi-ecosystem updates +intro: Multi-ecosystem updates combine dependency updates across multiple package ecosystems into a single pull request, reducing review overhead and simplifying your update workflow. +contentType: concepts +versions: + feature: dependabot-multi-ecosystem-support +shortTitle: Multi-ecosystem updates +--- + +## What are multi-ecosystem updates? + +Multi-ecosystem updates allow {% data variables.product.prodname_dependabot %} to group dependency updates across different package ecosystems such as npm, Docker, Python, and Terraform into a single pull request per group. + +Instead of receiving separate pull requests for each ecosystem, you receive one consolidated pull request containing all updates for the ecosystems in that group. + +## How multi-ecosystem updates work + +When you configure a multi-ecosystem group: + +1. You define the group with a schedule in the `multi-ecosystem-groups` section of your `dependabot.yml` file. +1. You assign individual package ecosystems to the group using the `multi-ecosystem-group` key. +1. You specify which dependencies to include using the `patterns` key for each ecosystem. +1. {% data variables.product.prodname_dependabot %} checks for updates according to the group's schedule. +1. A single pull request is created containing updates from all ecosystems in the group. +1. The PR uses the group identifier in both the branch name and title. + +## When to use multi-ecosystem updates + +Multi-ecosystem updates are particularly useful for: + +* **Infrastructure projects** that use multiple technologies (Docker, Terraform, Python scripts) +* **Full-stack applications** with frontend and backend dependencies that should be updated together +* **Cross-platform libraries** that need synchronized protocol versions across languages +* **Monorepos** with services in different languages that share versioning + +## Multi-ecosystem versus single-ecosystem groups + +{% data variables.product.prodname_dependabot %} supports two types of grouping: + +**Multi-ecosystem groups:** +* Span multiple `package-ecosystem` entries in your `dependabot.yml` file +* Require the `patterns` key to specify which dependencies to include +* Have their own schedule defined in the `multi-ecosystem-groups` section +* Use the `multi-ecosystem-group` key to assign ecosystems to a group + +**Single-ecosystem groups:** +* Work within one package ecosystem +* Use the `groups` key within an `updates` entry +* Inherit the schedule from the parent `updates` entry +* Better for organizing dependencies within a single package manager + +Use multi-ecosystem groups when you want to combine updates across different package managers. Use single-ecosystem groups when you want to organize dependencies within a single package manager (for example, grouping all AWS-related npm packages together). + +### Configuration merging behavior + +Some configuration options can be set at both the group level and ecosystem level. {% data variables.product.prodname_dependabot %} combines these values differently depending on the option: + +**Additive options** (values are merged): +* `assignees` - All assignees from both levels are assigned to the pull request +* `labels` - All labels from both levels are applied to the pull request + +For example, if you assign `@platform-team` at the group level and `@docker-admin` at the Docker ecosystem level, the resulting pull request will be assigned to both `@platform-team` and `@docker-admin`. + +**Group-only options** (can only be set at group level): +* `milestone` +* `commit-message` +* `target-branch` +* `pull-request-branch-name` + +Attempting to set these options at the ecosystem level will cause a configuration error. + +For a complete reference of all available configuration options and their behavior, see [AUTOTITLE](/code-security/reference/supply-chain-security/dependabot-options-reference#multi-ecosystem-groups). + +## Use cases + +### Infrastructure projects + +Infrastructure code often uses multiple technologies—Docker containers, Terraform for cloud resources, and Python scripts for automation. Grouping these updates together simplifies review and deployment coordination. + +**Why group these together:** Infrastructure changes often need to be deployed together. Having separate PRs for each technology creates coordination overhead and makes it harder to track what needs to be deployed as a unit. + +**Example scenario:** You have Docker images for your services, Terraform modules for AWS resources, and Python scripts for automation tasks. A single weekly "infrastructure" pull request contains updates for all three, making it easier to review and deploy infrastructure changes together. + +### Full-stack applications + +Web applications with frontend and backend components benefit from updating dependencies together to ensure compatibility and streamline testing. + +**Why group these together:** Frontend and backend often depend on each other. Updating them together ensures you can test the full application stack in one go, rather than merging frontend changes and then discovering backend incompatibilities later. + +**Example scenario:** Your React frontend and Rails backend are updated daily in a single "app-dependencies" pull request, allowing you to test the complete application together before merging. + +### Cross-platform libraries + +Libraries or services that use the same protocols across different languages (like gRPC and Protocol Buffers) need to keep library versions synchronized across all implementations. + +**Why group these together:** Protocol libraries need to stay compatible across different language implementations. Updating them together prevents version mismatches that could cause communication failures between services. + +**Example scenario:** Your Node.js and Ruby services both use gRPC. A single pull request updates both `@grpc/grpc-js` (npm) and `grpc` (bundler) together, ensuring protocol compatibility. + +### Monorepos with multiple services + +Large repositories containing multiple services in different languages benefit from grouping updates by team responsibility or deployment cadence. + +**Why group these together:** Different teams own different parts of the monorepo, and updates should be routed to the appropriate reviewers. Or services are deployed together and need coordinated updates. + +**Example scenario:** Your monorepo has a Python API service, a Go worker service, and a Node.js frontend. You create separate groups for "backend-services" (Python + Go) and "frontend" (Node.js), each with different schedules and assignees. + +## Example: Complex multi-group configuration + +This example shows how a complex project might use multiple groups with different update strategies: + +```yaml copy +version: 2 + +multi-ecosystem-groups: + # Infrastructure updates - weekly, tracked in milestone + infrastructure: + schedule: + interval: "weekly" + assignees: ["@platform-team"] + labels: ["infrastructure", "dependencies"] + milestone: 10 + + # Application code updates - daily, with development team + full-stack: + schedule: + interval: "daily" + assignees: ["@full-stack-team"] + labels: ["full-stack"] + +updates: + # Docker images - infrastructure group with additional docker expertise + - package-ecosystem: "docker" + directory: "/" + patterns: ["nginx", "redis", "postgres"] + assignees: ["@docker-admin"] # Adds to @platform-team + labels: ["docker"] # Adds to infrastructure, dependencies + multi-ecosystem-group: "infrastructure" + + # Terraform - infrastructure group + - package-ecosystem: "terraform" + directory: "/" + patterns: ["aws", "terraform-*"] + multi-ecosystem-group: "infrastructure" + + # Frontend - full-stack group with frontend focus + - package-ecosystem: "npm" + directory: "/frontend" + patterns: ["react", "lodash", "@types/*"] + labels: ["frontend"] # Adds to full-stack + multi-ecosystem-group: "full-stack" + + # Backend - full-stack group with backend specialist + - package-ecosystem: "bundler" + directory: "/backend" + patterns: ["rails", "pg", "sidekiq"] + assignees: ["@backend-dev"] # Adds to @full-stack-team + multi-ecosystem-group: "full-stack" +``` + +## Next steps + +* [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates) \ No newline at end of file diff --git a/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates.md b/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates.md new file mode 100644 index 000000000000..d41daabb602c --- /dev/null +++ b/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates.md @@ -0,0 +1,118 @@ +--- +title: Configuring multi-ecosystem updates for Dependabot +intro: Reduce the number of {% data variables.product.prodname_dependabot %} pull requests you receive by grouping updates across multiple ecosystems into a single, consolidated pull request. +permissions: '{% data reusables.permissions.dependabot-yml-configure %}' +allowTitleToDifferFromFilename: true +contentType: how-tos +versions: + feature: dependabot-multi-ecosystem-support +topics: + - Dependabot + - Version updates + - Repositories + - Dependencies + - Pull requests +shortTitle: Configure multi-ecosystem updates +redirect_from: + - /code-security/dependabot/working-with-dependabot/configuring-multi-ecosystem-updates + - /code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates +--- + +Multi-ecosystem updates allow you to consolidate {% data variables.product.prodname_dependabot %} pull requests across different package ecosystems into a single PR per group. See [AUTOTITLE](/code-security/concepts/supply-chain-security/multi-ecosystem-updates). + +## Prerequisites +* A repository with dependencies in multiple package ecosystems +* An existing `.github/dependabot.yml` file. See [AUTOTITLE](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates). + +## 1. Define your multi-ecosystem group in your `.github/dependabot.yml` file + +Start by defining a group with a schedule in the top-level `multi-ecosystem-groups` section: + +```yaml copy +version: 2 + +multi-ecosystem-groups: + infrastructure: + schedule: + interval: "weekly" + +updates: + # Your existing package ecosystems will go here +``` + +## 2. Assign ecosystems to the group + +Add the `multi-ecosystem-groups` key and patterns to your package ecosystem configurations. + +```yaml copy +version: 2 + +multi-ecosystem-groups: + infrastructure: + schedule: + interval: "weekly" + +updates: + - package-ecosystem: "docker" + directory: "/" + patterns: ["nginx", "redis", "postgres"] + multi-ecosystem-group: "infrastructure" + + - package-ecosystem: "terraform" + directory: "/" + patterns: ["aws", "terraform-*"] + multi-ecosystem-group: "infrastructure" +``` + +> [!NOTE] +> Use `["*"]` to include all dependencies. + +## 3. Commit your changes + +Commit the changes to your `dependabot.yml` file. + +## 4. Customize with additional keys (optional) + +You can add labels, reviewers, or other configuration options to your multi-ecosystem groups. See [`assignees`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#assignees--) and [`labels`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#labels--). + +```yaml copy +multi-ecosystem-groups: + infrastructure: + schedule: + interval: "weekly" + assignees: ["@platform-team"] + labels: ["infrastructure", "dependencies"] + +updates: + - package-ecosystem: "docker" + directory: "/" + patterns: ["nginx", "redis", "postgres"] + multi-ecosystem-group: "infrastructure" + + - package-ecosystem: "terraform" + directory: "/" + patterns: ["aws", "terraform-*"] + multi-ecosystem-group: "infrastructure" +``` + +For a complete list of available options, see [AUTOTITLE](/code-security/reference/supply-chain-security/dependabot-options-reference#multi-ecosystem-groups). + +## 5. Verify your configuration + +After committing your changes, you can verify the configuration: + +1. Navigate to your repository's **Insights** tab. +1. Select **Dependency graph**, then **{% data variables.product.prodname_dependabot %}**. +1. Confirm your multi-ecosystem group appears in the list. + +The next time the scheduled update runs, you'll receive a single pull request with updates from all ecosystems in the group. + +## Troubleshooting + +If you're not seeing consolidated pull requests, ensure that: +* The `patterns` key is defined for each ecosystem (required when using `multi-ecosystem-group`). +* All ecosystems use the same group name in the `multi-ecosystem-group` field. + +## Further reading + +* [AUTOTITLE](/code-security/dependabot/working-with-dependabot/dependabot-options-reference) diff --git a/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/index.md b/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/index.md index ee3743a1e504..b40045038751 100644 --- a/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/index.md +++ b/content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/index.md @@ -12,6 +12,7 @@ children: - /configuring-dependabot-security-updates - /configuring-dependabot-version-updates - /keeping-your-actions-up-to-date-with-dependabot + - /configuring-multi-ecosystem-updates - /enabling-the-dependency-graph - /exploring-the-dependencies-of-a-repository - /configuring-automatic-dependency-submission-for-your-repository diff --git a/content/code-security/reference/supply-chain-security/dependabot-options-reference.md b/content/code-security/reference/supply-chain-security/dependabot-options-reference.md index 710f75f46393..e1615c8adc29 100644 --- a/content/code-security/reference/supply-chain-security/dependabot-options-reference.md +++ b/content/code-security/reference/supply-chain-security/dependabot-options-reference.md @@ -441,7 +441,7 @@ Supported value: the numeric identifier of a milestone. >[!TIP] >If you view a milestone, the final part of the page URL, after `milestone`, is the identifier. For example: `https://github.com///milestone/3`, see [AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/viewing-your-milestones-progress). -{% ifversion not ghes %} +{% ifversion dependabot-multi-ecosystem-support %} ## `multi-ecosystem-groups` {% octicon "versions" aria-label="Version updates" height="24" %} diff --git a/content/code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates.md b/content/code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates.md deleted file mode 100644 index 91137c4edd70..000000000000 --- a/content/code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates.md +++ /dev/null @@ -1,407 +0,0 @@ ---- -title: Configuring multi-ecosystem updates for Dependabot -intro: Learn how to configure {% data variables.product.prodname_dependabot %} to group updates across different ecosystems so that you receive a single, consolidated pull request per group instead of one pull request for each ecosystem. -permissions: '{% data reusables.permissions.dependabot-yml-configure %}' -allowTitleToDifferFromFilename: true -contentType: tutorials -versions: - fpt: '*' - ghec: '*' - ghes: '>=3.19' -topics: - - Dependabot - - Version updates - - Repositories - - Dependencies - - Pull requests -shortTitle: Configure multi-ecosystem updates -redirect_from: - - /code-security/dependabot/working-with-dependabot/configuring-multi-ecosystem-updates ---- - -## About multi-ecosystem updates - -Multi-ecosystem updates allow you to create groups that span multiple package ecosystems and get a single {% data variables.product.prodname_dependabot %} pull request with updates across all supported ecosystems. This approach helps reduce the number of {% data variables.product.prodname_dependabot %} pull requests you receive and streamlines your dependency update workflow. - -Multi-ecosystem updates are particularly useful for: - -* **Infrastructure projects** that use multiple technologies (Docker, Terraform, Python scripts). -* **Full-stack applications** with frontend and backend dependencies that should be updated together. -* **Cross-platform libraries** that need synchronized protocol versions across languages. - -## Getting Started - -You should follow these instructions to set up your first multi-ecosystem group. - -### 1. Add `multi-ecosystem-groups` to your `.github/dependabot.yml` file - -Start by defining a group with a schedule in the top-level `multi-ecosystem-groups` section: - -```yaml copy -version: 2 - -multi-ecosystem-groups: - infrastructure: - schedule: - interval: "weekly" - -updates: - # Your existing package ecosystems will go here -``` - -### 2. Assign ecosystems to groups with patterns - -1. Add the `multi-ecosystem-group` key. -1. Add `patterns` to your package ecosystem configurations. - -```yaml copy -version: 2 - -multi-ecosystem-groups: - infrastructure: - schedule: - interval: "weekly" - -updates: - - package-ecosystem: "docker" - directory: "/" - patterns: ["nginx", "redis", "postgres"] - multi-ecosystem-group: "infrastructure" - - - package-ecosystem: "terraform" - directory: "/" - patterns: ["aws", "terraform-*"] - multi-ecosystem-group: "infrastructure" -``` - -> [!IMPORTANT] -> The `patterns` key is required when using `multi-ecosystem-group`. You can specify dependency patterns to include only certain dependencies in the group, or use `["*"]` to include all dependencies. - -### 3. Commit and watch for consolidated pull requests - -Once you commit the changes to your `dependabot.yml` file, {% data variables.product.prodname_dependabot %} will: - -* Check for updates according to the group's schedule -* Check for updates according to the group's schedule. -* Create a single pull request containing updates for all the ecosystems specified in the group. -* Use the group identifier in the branch name and the pull request title. - -### 4. Customize with additional keys (optional) - -Add [`assignees`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#assignees--), [`labels`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#labels--), and other settings to your groups: - -```yaml copy -multi-ecosystem-groups: - infrastructure: - schedule: - interval: "weekly" - assignees: ["@platform-team"] - labels: ["infrastructure", "dependencies"] - -updates: - - package-ecosystem: "docker" - directory: "/" - patterns: ["nginx", "redis", "postgres"] - multi-ecosystem-group: "infrastructure" - - - package-ecosystem: "terraform" - directory: "/" - patterns: ["aws", "terraform-*"] - multi-ecosystem-group: "infrastructure" -``` - -## Multi-ecosystem specific configuration - -Multi-ecosystem updates use a two-level configuration structure to provide flexibility and control over how updates are grouped and managed: - -* **Group-level** (`multi-ecosystem-groups`): This is where you define the overall group behavior, scheduling, and shared settings that apply to all package ecosystems in the group. -* **Ecosystem-level** (`updates`): Configure individual package managers within the group, including which dependencies to include and ecosystem-specific settings. - -This structure allows you to set consistent policies at the group level while maintaining fine-grained control over individual package ecosystems. - -### `multi-ecosystem-groups` - -Define groups that span multiple package ecosystems. Each group requires: - -* **Group identifier**: Used in branch names and pull request titles. -* **Schedule**: How often to check for updates. See [schedule](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-) for all available options. - -### `multi-ecosystem-group` - -Assign a package ecosystem to a multi-ecosystem group. Requires the `patterns` key to specify which dependencies to include. - -For more information about `patterns`, see [`patterns` and `exclude-patterns`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#patterns-and-exclude-patterns-groups). - -### Additional configuration options - -All standard {% data variables.product.prodname_dependabot %} configuration options can be used with multi-ecosystem groups. See [`package-ecosystem`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#package-ecosystem-), [`directory`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#directories-or-directory--), [`allow`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#allow--), [`ignore`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#ignore--), [`cooldown`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-), and [`registries`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#registries--) in [AUTOTITLE](/code-security/dependabot/working-with-dependabot/dependabot-options-reference). - -## Key configuration - -When using multi-ecosystem groups, keys are configured at two levels. Here's a complete breakdown of which keys can be used where: - -### Group-level (`multi-ecosystem-groups`) - -The following table shows the configuration keys available at the group level, along with their behavior types. For more information, see [Configuration behavior](#configuration-behavior). - -| Key | Required | Behavior | -|---------------------|:--------:|:----------------| -| [`schedule`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-) |{% octicon "check" aria-label="Required" %}| Not applicable | -| [`labels`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#labels--) |{% octicon "x" aria-label="Not required" %}| Additive | -| [`milestone`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#milestone--) | {% octicon "x" aria-label="Not required" %} | Group-only | -| [`assignees`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#assignees--) |{% octicon "x" aria-label="Not required" %} |Additive | -| [`target-branch`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#target-branch-) |{% octicon "x" aria-label="Not required" %} |Group-only | -| [`commit-message`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#commit-message--) |{% octicon "x" aria-label="Not required" %} |Group-only | -| [`pull-request-branch-name`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#pull-request-branch-nameseparator--) |{% octicon "x" aria-label="Not required" %} |Group-only | - -### Ecosystem-level (`updates`) - -The following table shows the configuration keys available at the ecosystem level, along with their behavior types. For more information, see [Configuration behavior](#configuration-behavior). - -| Key | Required | Behavior | -|---------------------|:--------:|:----------------| -| [`package-ecosystem`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#package-ecosystem-) |{% octicon "check" aria-label="Required" %}| Not applicable | -| [`directory` / `directories`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#directories-or-directory--) |{% octicon "check" aria-label="Required" %}| Not applicable | -| [`patterns`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#patterns-and-exclude-patterns-groups) |{% octicon "check" aria-label="Required" %}| Not applicable | -| [`allow`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#allow--) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`ignore`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#ignore--) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`registries`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#registries--) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`vendor`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#vendor--) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`versioning-strategy`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#versioning-strategy--) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`update-types`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#update-types-groups) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`cooldown`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-) |{% octicon "x" aria-label="Not required" %}| Not applicable | -| [`labels`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#labels--) | {% octicon "x" aria-label="Not required" %} | Additive | -| [`assignees`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#assignees--) |{% octicon "x" aria-label="Not required" %} |Additive | - -### Configuration behavior - -#### Additive keys - -Additive keys merge values from both the group level and individual ecosystem level rather than one overriding the other. This allows you to set consistent team-wide configurations at the group level while adding specific ecosystem expertise at the individual level. - -* `assignees` - All assignees from both group and ecosystem levels are assigned -* `labels` - All labels from both group and ecosystem levels are applied - -This table shows how {% data variables.product.prodname_dependabot %} combines values from both group and ecosystem levels for Docker pull requests in the example below: - -| Option | Group-level value | Ecosystem-level value | Result | -|-----------|------------------------------------- |-------------------------|--------------------------------------------------------------| -| `assignees` | `@platform-team`, `@security-lead` | `@docker-admin` | `@platform-team`, `@security-lead`, `@docker-admin` | -| `labels` | `infrastructure`, `dependencies` | `docker`, `containers` | `infrastructure`, `dependencies`, `docker`, `containers` | - -```yaml copy -multi-ecosystem-groups: - infrastructure: - assignees: ["@platform-team", "@security-lead"] - labels: ["infrastructure", "dependencies"] - -updates: - - package-ecosystem: "docker" - assignees: ["@docker-admin"] - labels: ["docker", "containers"] - multi-ecosystem-group: "infrastructure" -``` - -#### Group-only keys - -* `milestone` - Integer milestone number -* `commit-message` - Commit message templates -* `target-branch` - Target branch for pull requests -* `pull-request-branch-name` - Branch naming configuration - -> [!WARNING] -> If you attempt to set group-only keys at the ecosystem level (in `updates` entries), {% data variables.product.prodname_dependabot %} will throw a configuration error and fail to process your `dependabot.yml` file. These keys must only be specified in the `multi-ecosystem-groups` section. - -**Example:** - -This table shows how {% data variables.product.prodname_dependabot %} combines values from both group and ecosystem levels for Docker pull requests in the example below: - -| Option | Group-level value | Ecosystem-level value | Result | -|-----------|---------------------|-------------------------|----------------------------------------| -| `assignees` | `@platform-team` | `@docker-admin` | `@platform-team`, `@docker-admin` | -| `labels` | `infrastructure` | `docker`, `containers` | `infrastructure`, `docker`, `containers`| - -```yaml copy -multi-ecosystem-groups: - infrastructure: - assignees: ["@platform-team"] - labels: ["infrastructure"] - -updates: - - package-ecosystem: "docker" - assignees: ["@docker-admin"] - labels: ["docker", "containers"] - multi-ecosystem-group: "infrastructure" -``` - -## Use cases and examples - -Multi-ecosystem updates are particularly useful for projects that use multiple package managers and want to coordinate updates across them. Here are common scenarios: - -### Infrastructure projects - -**Scenario**: Your infrastructure code uses multiple technologies - Docker containers, Terraform for cloud resources, and Python scripts for automation. You want all infrastructure-related updates grouped together for easier review and deployment coordination. - -**Why group these together**: Infrastructure changes often need to be deployed together, and having separate PRs for each technology creates coordination overhead. - -```yaml copy -multi-ecosystem-groups: - infrastructure: - schedule: - interval: "weekly" # Weekly updates to avoid disruption - -updates: - - package-ecosystem: "docker" - directory: "/" - patterns: ["nginx", "redis", "postgres"] - multi-ecosystem-group: "infrastructure" - - package-ecosystem: "terraform" - directory: "/" - patterns: ["aws", "terraform-*"] - multi-ecosystem-group: "infrastructure" - - package-ecosystem: "pip" - directory: "/" - patterns: ["boto3", "requests", "pyyaml"] - multi-ecosystem-group: "infrastructure" -``` - -**Result**: One weekly pull request containing updates for Docker images, Terraform providers, and Python dependencies used in infrastructure automation. - -### Full-stack applications - -**Scenario**: You have a web application with a React frontend and Rails backend. You want frontend and backend dependencies updated together to ensure compatibility and streamline testing. - -**Why group these together**: Frontend and backend often depend on each other, and updating them together ensures you can test the full application stack in one go. - -```yaml copy -multi-ecosystem-groups: - app-dependencies: - schedule: - interval: "daily" # More frequent updates for application code - -updates: - - package-ecosystem: "npm" - directory: "/frontend" - patterns: ["react", "lodash", "@types/*"] # Core frontend libraries and TypeScript types - multi-ecosystem-group: "app-dependencies" - - package-ecosystem: "bundler" - directory: "/backend" - patterns: ["rails", "pg", "sidekiq"] # Core backend framework and database - multi-ecosystem-group: "app-dependencies" -``` - -**Result**: Daily PRs containing both frontend JavaScript/TypeScript updates and backend Ruby gem updates, allowing you to test the complete application together. - -### Cross-platform libraries - -**Scenario**: You're building a library or service that uses the same protocols across different languages (like gRPC and Protocol Buffers). You want to keep the library versions synchronized across all implementations. - -**Why group these together**: Protocol libraries need to stay compatible across different language implementations, so updating them together prevents version mismatches. - -```yaml copy -multi-ecosystem-groups: - grpc-and-protobuf: - schedule: - interval: "daily" - -updates: - - package-ecosystem: "bundler" - directory: "/grpc-proto-test/" - patterns: ["grpc", "google-protobuf"] - multi-ecosystem-group: "grpc-and-protobuf" - - package-ecosystem: "npm" - directory: "/grpc-proto-test/" - patterns: ["@grpc/grpc-js", "google-protobuf"] - multi-ecosystem-group: "grpc-and-protobuf" -``` - -**Result**: Daily PRs ensuring that Ruby and Node.js gRPC libraries stay synchronized, preventing protocol compatibility issues. - -## Advanced configuration example - -This comprehensive example shows how a complex project might use multiple groups with different update strategies and key merging: - -```yaml copy -version: 2 - -multi-ecosystem-groups: - infrastructure: - schedule: - interval: "weekly" - assignees: ["@platform-team"] # assign platform team - labels: ["infrastructure", "dependencies"] - milestone: 10 # Track in milestone - commit-message: - prefix: "infra" - include: "scope" - - # Application code updates - daily, with development team - full-stack: - schedule: - interval: "daily" - assignees: ["@full-stack-team"] # assign to full-stack team - labels: ["full-stack"] - -updates: - # Docker images - infrastructure group with additional docker expertise - - package-ecosystem: "docker" - directory: "/" - patterns: ["nginx", "redis", "postgres"] - assignees: ["@docker-admin"] # adds to @platform-team (additive) - labels: ["docker"] # adds to infrastructure, dependencies (additive) - multi-ecosystem-group: "infrastructure" - - # Terraform - infrastructure group with terraform specialists - - package-ecosystem: "terraform" - directory: "/" - patterns: ["aws", "terraform-*"] - multi-ecosystem-group: "infrastructure" - - # Frontend - full-stack group with frontend focus - - package-ecosystem: "npm" - directory: "/frontend" - patterns: ["react", "lodash", "@types/*"] - labels: ["frontend"] # adds to full-stack (additive) - multi-ecosystem-group: "full-stack" - - # Backend - full-stack group with backend specialist - - package-ecosystem: "bundler" - directory: "/backend" - patterns: ["rails", "pg", "sidekiq"] - assignees: ["@backend-dev"] # adds to @full-stack-team (additive) - multi-ecosystem-group: "full-stack" -``` - -### How this configuration works - -#### Infrastructure PRs - -* `schedule: weekly` - -| Option| Group-level value | Ecosystem-level value | Result | -|---------|------------|-----------------|--------| -| `assignees` | `@platform-team` | `@docker-admin` (Docker), `@terraform-experts` (Terraform) | All combined | -| `labels` | `infrastructure`, `dependencies` | `docker` (Docker) | All combined | -| `schedule` | `weekly` | None | Weekly updates | -| `milestone` | `10` | None | Tracked in milestone 10 | - -#### Full-stack PRs - -* `schedule: daily` - -| Option | Group-level value | Ecosystem-level value | Result | -|---------|------------|-----------------|--------| -| `assignees` | `@full-stack-team` | `@backend-dev` (Backend) | All combined | -| `labels` | `full-stack` | `frontend` (Frontend) | All combined | -| `schedule` | `daily` | None | More frequent updates | - -This approach ensures that the right people are involved for each type of update while maintaining consistent policies across related technologies. - -## Best practices - -* **Group related dependencies**: Only group ecosystems that logically belong together. -* **Use descriptive identifiers**: Choose group names that clearly indicate the group's purpose. - -### Further reading - -* [AUTOTITLE](/code-security/dependabot/working-with-dependabot/dependabot-options-reference) diff --git a/content/code-security/tutorials/secure-your-dependencies/index.md b/content/code-security/tutorials/secure-your-dependencies/index.md index d5b67dcd3dad..6de1520562b6 100644 --- a/content/code-security/tutorials/secure-your-dependencies/index.md +++ b/content/code-security/tutorials/secure-your-dependencies/index.md @@ -12,7 +12,7 @@ children: - /automating-dependabot-with-github-actions - /optimizing-pr-creation-version-updates - /setting-dependabot-to-run-on-self-hosted-runners-using-arc - - /configuring-multi-ecosystem-updates - /customizing-dependabot-prs - /customizing-your-dependency-review-action-configuration --- + diff --git a/data/features/dependabot-multi-ecosystem-support.yml b/data/features/dependabot-multi-ecosystem-support.yml new file mode 100644 index 000000000000..02f84d0fd6e9 --- /dev/null +++ b/data/features/dependabot-multi-ecosystem-support.yml @@ -0,0 +1,6 @@ +# Reference: #18591 +# Single pull request for all Dependabot Updates (multi-ecosystem support +versions: + fpt: '*' + ghec: '*' + ghes: '> 3.21'