多生态系统更新

多生态系统更新将跨多个软件包生态系统的依赖更新合并为一个拉取请求，减少审查工作量并简化更新工作流。

本文内容

什么是多生态系统更新？

多生态系统更新允许 Dependabot 将 npm、Docker、Python 和 Terraform 等不同软件包生态系统的依赖更新按组合并为单个拉取请求。

与其为每个生态系统接收单独的拉取请求，你会收到一个包含该组中所有生态系统更新的合并拉取请求。

多生态系统更新如何工作

当你配置多生态系统组时

  1. 你在 dependabot.yml 文件的 multi-ecosystem-groups 部分为该组定义调度计划。
  2. 你使用 multi-ecosystem-group 键将各个软件包生态系统分配到该组。
  3. 你使用每个生态系统的 patterns 键指定要包含的依赖项。
  4. Dependabot 按照该组的调度计划检查更新。
  5. 将创建一个包含该组所有生态系统更新的单一拉取请求。
  6. 该 PR 在分支名称和标题中均使用组标识符。

何时使用多生态系统更新

多生态系统更新在以下情况下特别有用：

  • 基础设施项目 使用多种技术（Docker、Terraform、Python 脚本）
  • 全栈应用程序 前端和后端依赖应一起更新
  • 跨平台库 需要跨语言同步协议版本
  • 单体仓库 包含不同语言的服务且共享版本控制

多生态系统组与单生态系统组的比较

Dependabot 支持两种分组方式

多生态系统组

  • 跨越 dependabot.yml 文件中多个 package-ecosystem 条目
  • 需要 patterns 键来指定要包含的依赖项
  • 在 multi-ecosystem-groups 部分定义各自的调度计划
  • 使用 multi-ecosystem-group 键将生态系统分配到组

单生态系统组

  • 在单一软件包生态系统内工作
  • 在 updates 条目中使用 groups 键
  • 从父级 updates 条目继承调度
  • 更适合在单一包管理器内组织依赖

当希望跨不同包管理器合并更新时使用多生态系统组。当希望在单一包管理器内组织依赖时使用单生态系统组（例如，将所有与 AWS 相关的 npm 包归为一组）。

配置合并行为

某些配置选项可以在组级别和生态系统级别同时设置。Dependabot 会根据选项的不同，以不同方式合并这些值。

累加选项（值会合并）

  • assignees - 两个层级的所有指派人都会被分配到该拉取请求。
  • labels - 两个层级的所有标签都会应用到该拉取请求。

例如，如果你在组级别分配了 @platform-team，在 Docker 生态系统级别分配了 @docker-admin，则生成的拉取请求会同时分配给 @platform-team 和 @docker-admin。

仅组级选项（只能在组级设置）

  • 里程碑
  • commit-message
  • target-branch
  • pull-request-branch-name

尝试在生态系统级别设置这些选项将导致配置错误。

有关所有可用配置选项及其行为的完整参考，请参阅 Dependabot 选项参考。

使用场景

基础设施项目

基础设施代码通常使用多种技术——Docker 容器、用于云资源的 Terraform，以及用于自动化的 Python 脚本。将这些更新分组在一起可简化审查和部署协调。

为何将它们分组：基础设施变更通常需要一起部署。为每种技术单独创建 PR 会增加协调开销，并且更难跟踪需要作为整体部署的内容。

示例场景：你的服务有 Docker 镜像，AWS 资源有 Terraform 模块，自动化任务有 Python 脚本。每周一个 “infrastructure” 拉取请求包含这三者的更新，使一起审查和部署基础设施变更更加容易。

全栈应用程序

具有前端和后端组件的 Web 应用程序受益于一起更新依赖，以确保兼容性并简化测试。

为何将它们分组：前端和后端往往相互依赖。一起更新可确保一次性测试完整的应用程序堆栈，而不是先合并前端更改后才发现后端不兼容。

示例场景：你的 React 前端和 Rails 后端每天在单个 “app-dependencies” 拉取请求中更新，使你能够在合并前一起测试完整的应用程序。

跨平台库

在不同语言间使用相同协议的库或服务（如 gRPC 和 Protocol Buffers）需要在所有实现中保持库版本同步。

为何将它们分组：协议库必须在不同语言实现之间保持兼容。一起更新可防止版本不匹配导致服务之间通信失败。

示例场景：你的 Node.js 和 Ruby 服务都使用 gRPC。单个拉取请求同时更新 @grpc/grpc-js（npm）和 grpc（bundler），确保协议兼容性。

包含多个服务的单体仓库

包含多语言服务的大型仓库可通过按团队职责或部署节奏对更新进行分组受益。

为何将它们分组：不同团队拥有单体仓库的不同部分，更新应路由到相应的审查者。或者服务一起部署，需要协调更新。

示例场景：你的单体仓库包含 Python API 服务、Go 工作服务和 Node.js 前端。你为 “backend-services”（Python + Go）和 “frontend”（Node.js）创建了独立的分组，每个分组都有不同的调度和指派人。

示例：复杂的多组配置

此示例展示了复杂项目如何使用具有不同更新策略的多个分组。

YAML
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"

后续步骤

© . This site is unofficial and not affiliated with GitHub, Inc.