Skip to main content

Enterprise Server 3.16 目前作为候选发布提供。

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

了解如何简化和高效地管理 Dependabot 拉取请求。

谁可以使用此功能?

Users with write access

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

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

你可以实施一些自定义选项来优化 Dependabot 更新拉取请求,以符合你的流程,例如:

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

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

Dependabot 按照配置文件中设置的频率(其中必需的字段 schedule.interval 必须设置为 dailyweeklymonthly)检查版本更新。

默认情况下,Dependabot 会分配一个随机时间来检查并提出依赖项更新的拉取请求,以均衡其工作负载。

但是,为了减少干扰,或者为了更好地组织时间和资源来审阅和处理版本更新,你可能会发现修改频率和时间很有用。 例如,你可能希望 Dependabot 运行每周(而不是每日)更新检查,以及在某个特定时间运行更新检查,以确保在团队会审会话之前提出拉取请求。

可以将 schedule 与选项组合一起使用,以修改 Dependabot 检查版本更新的频率和时间

下面的示例 dependabot.yml 文件更改了 npm 配置,指定 Dependabot 应在日本标准时间 (UTC +09:00) 每天 02:00 检查 npm 依赖项的版本更新。

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

另请参阅计划

优先处理有意义的更新

可以使用 groups 将多个依赖项的更新合并到单个拉取请求中。 这有助于将审阅时间集中在高风险更新上,并最大程度地减少审阅次要版本更新所花费的时间。 例如,可以将开发依赖项的次要更新或补丁更新合并到单个拉取请求中,并为影响代码库关键区域的安全更新或版本更新设置一个专用组。

必须为每个包生态系统配置组,然后可以使用标准组合为每个包生态系统创建多个组:

  • Dependabot 更新类型:applies-to
  • 依赖项类型:dependency-type
  • 依赖项名称:patternsexclude-patterns
  • 语义化版本控制级别:update-types

若要查看每个标准支持的所有值,请参阅 groups

下面的示例介绍了使用标准创建依赖项组的几种不同方法。

示例 1:三个版本更新组

在本示例中,dependabot.yml 文件:

  • 创建名为 production-dependenciesdevelopment-dependenciesrubocop 的三个组。
  • 使用 patternsdependency-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_ruboconfiggocardless-* 匹配的依赖项排除在组外,Dependabot 继续为这些依赖项提出单个拉取请求。 如果需要对这些依赖项的更新进行更仔细的审查,这将很有帮助。
  • 对于 support-dependencies,Dependabot 将仅为版本更新提出拉取请求。

示例 3:主要更新的单个拉取请求和次要/补丁更新的分组拉取请求

在本示例中,dependabot.yml 文件:

  • 创建名为 angular 的组。
  • 使用与依赖项的名称匹配的 patterns 将依赖项包含在组中。
  • 使用 update-type 仅将 minorpatch 更新包含在组中。
  • 由于使用了 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 文件:

  • 创建名为 angularminor-and-patch 的两个组。
  • 使用 applies-to 使第一组仅适用于版本更新,第二组仅适用于安全更新。
  • 使用 update-type 仅包含这两个组的 minorpatch 更新。
  • 使用 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 的主要更新打开拉取请求。