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

默认情况下， Dependabot 打开一个新的拉取请求来更新每个依赖项。 启用安全更新后，发现易受攻击的依赖项时，就会打开新的拉取请求。 为一个或多个生态系统配置版本更新后，当有新版本的依赖项可用时，就会按照 dependabot.yml 文件中定义的频率打开新的拉取请求。

如果你的项目有很多依赖项，你可能会发现有大量的 Dependabot 拉取请求需要查看和合并，而且这很快就会变得难以管理。

可以通过几个自定义选项来优化 Dependabot 更新拉取请求以与流程保持一致，例如：

• 控制Dependabot检查您的依赖项新版本的频率schedule。
• ****。

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

Dependabot 会按照您在配置文件中设定的频率进行版本更新检查，其中必填字段必须设置为 daily、weekly、monthly、quarterly、semiannually、yearly 或 cron（见 cronjob）。

默认情况下， Dependabot 通过分配随机时间来检查和引发依赖项更新的拉取请求来平衡其工作负荷。

但是，为了减少干扰，或者为了更好地安排时间和资源来审阅和处理版本更新，你可能会发现修改频率和时间很有用。 例如，你可能更希望 Dependabot 每周运行一次更新检查，而非每日运行，并确保这些操作是在团队会审会话之前提交拉取请求的时间进行。

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

可以通过结合使用 schedule 选项来修改 Dependabot 检查版本更新的频率和时间。

dependabot.yml以下示例文件将更改 npm 配置，以指定应在Dependabot星期二 02：00 日本标准时间（UTC +09：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"

另请参阅计划。

为依赖项更新设置冷却期

可以使用 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 列表中允许的最大条目限制为各 150 个，这些列表可与 cooldown 配合使用。

大多数包管理器都支持 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 的主要更新打开拉取请求。

在单存储库中跨目录对更新进行分组

如果你管理一个单一代码库，其中包含多个共享常见依赖项的目录，可以通过按依赖项名称对所有目录的更新进行分组，从而减少版本更新的拉取请求数量。

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

• 为每个影响多个目录的依赖项更新创建单个拉取请求
• 在一次操作中，将同一依赖项更新为同一版本，适用于所有目录。
• 减少需要审查的拉取请求数量
• 通过只运行一次测试而不是在每个目录中运行测试来最大程度地降低 CI/CD 成本

有关详细信息，请参阅 group-by。

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

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