优化 Dependabot 版本更新的拉取请求创建

默认情况下，Dependabot 会为每个依赖打开一个新的拉取请求进行更新。启用安全更新后，发现存在漏洞的依赖时会打开新的拉取请求。当您为一个或多个生态系统配置版本更新时，只要有新版本的依赖可用，Dependabot 会按照 dependabot.yml 文件中定义的频率打开新的拉取请求。

如果您的项目有大量依赖，您可能会发现需要审查和合并的 Dependabot 拉取请求数量非常庞大，这会迅速变得难以管理。

您可以实现几种自定义选项，以优化 Dependabot 更新的拉取请求，使其更符合您的流程，例如

• 使用 schedule 控制 Dependabot 检查依赖新版本的频率。
• 使用 groups 优先处理有意义的更新。

控制依赖更新的频率和时间

Dependabot 按配置文件中您设置的频率运行版本更新检查，必填字段 schedule.interval 必须设为 daily、weekly、monthly、quarterly、semiannually、yearly 或 cron（参见 cronjob）。

默认情况下，Dependabot 会通过随机分配时间来检查并提出依赖更新的拉取请求，以平衡工作负载。

然而，为了减少干扰或更好地安排审查和处理版本更新的时间与资源，您可能希望修改频率和时间。例如，您可能更倾向于让 Dependabot 每周而非每日检查更新，并在确保拉取请求在团队分流会议前提交的时间点运行。

修改依赖更新的频率和时间

您可以使用 schedule 并结合多种选项，来修改 Dependabot 检查版本更新的频率和时间。

下面的示例 dependabot.yml 文件将 npm 配置修改为：Dependabot 应在每周二日本标准时间 (UTC +09:00) 02:00 检查 npm 依赖的版本更新。

# `dependabot.yml` file with
# customized schedule for version updates

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "02:00"
      timezone: "Asia/Tokyo"

# `dependabot.yml` file with
# customized schedule for version updates

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "02:00"
      timezone: "Asia/Tokyo"

另请参阅 schedule。

为依赖更新设置冷却期

您可以使用 cooldown 并结合多种选项，来控制 Dependabot 何时为版本更新创建拉取请求。

下面的示例 dependabot.yml 文件展示了对 requests、numpy 以及以 pandas 或 django 为前缀的依赖应用冷却期，但对精确匹配的 pandas 依赖则通过exclude 列表排除在外。

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
      include:
        - "requests"
        - "numpy"
        - "pandas*"
        - "django"
      exclude:
        - "pandas"

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
      include:
        - "requests"
        - "numpy"
        - "pandas*"
        - "django"
      exclude:
        - "pandas"

• 冷却天数必须在 1 到 90 天之间。
• 在 include 与 exclude 列表中可使用的最大项目数（可与 cooldown 一起使用）各为 150。

大多数包管理器都支持 SemVer。对处于冷却期的依赖的新版本更新会按以下方式推迟：

• 重大更新：延迟 30 天（semver-major-days: 30）。
• 次要更新：延迟 7 天（semver-minor-days: 7）。
• 补丁更新：延迟 3 天（semver-patch-days: 3）。

另请参阅 cooldown。

优先处理有意义的更新

将相关依赖分组在一起

您可以使用 groups 将多个依赖的更新合并为单个拉取请求。这有助于您将审查时间集中在风险更高的更新上，并减少审查次要版本更新所花的时间。例如，您可以将开发依赖的次要或补丁更新合并为一个拉取请求，并为影响代码库关键区域的安全或版本更新创建专门的分组。

必须在每个单独的包生态系统内配置分组，然后可以在同一生态系统内使用多种标准组合创建多个分组。

• Dependabot 更新类型：applies-to
• 依赖类型：dependency-type。
• 依赖名称：patterns 与 exclude-patterns
• 语义版本级别：update-types

要查看每个标准支持的全部取值，请参阅 groups。

下面的示例展示了使用这些标准创建依赖分组的几种不同方法。

示例 1：三个版本更新分组

在本示例中，dependabot.yml 文件

• 创建了三个分组，分别称为 “production-dependencies”、 “development-dependencies” 和 “rubocop”。
• 使用 patterns 与 dependency-type 将依赖包含进分组。
• 使用 exclude-patterns 将某个（或多个）依赖从分组中排除。

version: 2
updates:
  # Keep bundler dependencies up to date
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      production-dependencies:
        dependency-type: "production"
      development-dependencies:
        dependency-type: "development"
        exclude-patterns:
          - "rubocop*"
      rubocop:
        patterns:
          - "rubocop*"

因此

• 版本更新按依赖类型进行分组。
• 匹配模式 rubocop* 的开发依赖会从 development-dependencies 分组中排除。
• 相反，匹配 rubocop* 的开发依赖会被包含进 rubocop 分组。由于排序原因，匹配 rubocop* 的生产依赖则会被包含进 production-dependencies 分组。
• 此外，所有分组默认仅适用于版本更新，因为未出现 applies-to 键。

示例 2：带有排除依赖的分组更新

在本示例中，dependabot.yml 文件

• 创建了一个名为 “support-dependencies” 的分组，作为自定义 Bundler 配置的一部分。
• 使用匹配依赖名称（或多个依赖）的 patterns 将依赖包含进分组。
• 使用匹配依赖名称（或多个依赖）的 exclude-patterns 将依赖从分组中排除。
• 仅对版本更新应用分组，因为使用了 applies-to: version-updates。

version: 2
updates:
  # Keep bundler dependencies up to date
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"

    schedule:
      interval: "weekly"
    # Create a group of dependencies to be updated together in one pull request
    groups:
      # Specify a name for the group, which will be used in pull request titles
      # and branch names
      support-dependencies:
        # Define patterns to include dependencies in the group (based on
        # dependency name)
        applies-to: version-updates # Applies the group rule to version updates
        patterns:
          - "rubocop" # A single dependency name
          - "rspec*"  # A wildcard string that matches multiple dependency names
          - "*"       # A wildcard that matches all dependencies in the package
                      # ecosystem. Note: using "*" may open a large pull request
        # Define patterns to exclude dependencies from the group (based on
        # dependency name)
        exclude-patterns:
          - "gc_ruboconfig"
          - "gocardless-*"

因此

• 除以下情况外，绝大多数 Bundler 依赖都会因通配符 (“*”) 模式被整合到 support-dependencies 分组中：
• 匹配 gc_ruboconfig 和 gocardless-* 的依赖被排除在该分组之外，Dependabot 仍会为这些依赖单独创建拉取请求。如果这些依赖的更新需要更严谨的审查，这会很有帮助。
• 对于 support-dependencies，Dependabot 只会为版本更新创建拉取请求。

示例 3：重大更新单独拉取请求，次要/补丁更新合并拉取请求

在本示例中，dependabot.yml 文件

• 创建了一个名为 “angular” 的分组。
• 使用匹配依赖名称的 patterns 将依赖包含进分组。
• 使用 update-type 仅在分组中包含 minor 或 patch 更新。
• 仅对版本更新应用分组，因为使用了 applies-to: version-updates。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      # Specify a name for the group, which will be used in pull request titles
      # and branch names
      angular:
        applies-to: version-updates
        patterns:
          - "@angular*"
        update-types:
          - "minor"
          - "patch"

因此

• Dependabot 将为所有有次要或补丁更新的 Angular 依赖创建一个合并的拉取请求。
• 所有重大更新仍会以单独的拉取请求形式提出。

示例 4：次要/补丁更新合并拉取请求，重大更新不生成拉取请求

在本示例中，dependabot.yml 文件

• 创建了两个分组，分别为 “angular” 与 “minor-and-patch”。
• 使用 applies-to 使第一个分组仅适用于版本更新，第二个分组仅适用于安全更新。
• 对两个分组均使用 update-type 只包含 minor 或 patch 更新。
• 使用 ignore 条件排除对 @angular* 包的 major 版本更新。

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      angular:
        applies-to: version-updates
        patterns:
          - "@angular*"
        update-types:
          - "minor"
          - "patch"
      minor-and-patch:
        applies-to: security-updates
        patterns:
          - "@angular*"
        update-types:
          - "patch"
          - "minor"
    ignore:
      - dependency-name: "@angular*"
        update-types: ["version-update:semver-major"]

因此

• Angular 依赖的次要和补丁版本更新会合并为单个拉取请求。
• Angular 依赖的次要和补丁安全更新也会合并为单个拉取请求。
• Dependabot 不会自动为 Angular 的重大更新打开拉取请求。

在 monorepo 中跨目录分组更新

如果您管理的 monorepo 包含多个共享公共依赖的目录，可以通过跨所有目录按依赖名称分组更新，来减少版本更新的拉取请求数量。

当您配置 Dependabot 监视多个目录并启用按依赖名称分组时，Dependabot 将

• 为影响多个目录的每个依赖更新创建单个拉取请求
• 一次性在所有目录中将同一依赖更新到相同版本
• 减少需要审查的拉取请求数量
• 通过一次性运行测试而非对每个目录分别运行，来降低 CI/CD 成本

欲了解更多信息，请参阅 group-by。

此配置示例在 /frontend、/admin-panel 与 /mobile-app 目录中按依赖名称进行分组更新。如果 lodash 需要在这三个目录中全部更新，Dependabot 将创建一个名为 “Bump lodash in monorepo-dependencies group” 的单一拉取请求，以在所有位置统一更新 lodash。

version: 2
updates:
  - package-ecosystem: "npm"
    directories:
      - "/frontend"
      - "/admin-panel"
      - "/mobile-app"
    schedule:
      interval: "weekly"
    groups:
      monorepo-dependencies:
        group-by: dependency-name