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

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

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

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

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

* ```
            使用 ****Dependabot`schedule` 检查依赖项更新版本的频率。
  ```
* \*\*\*\*。

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

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

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

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

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

可以将 `schedule` 与各种选项结合使用来修改 Dependabot 检查版本更新的频率和时间。

`dependabot.yml`以下示例文件将更改 npm 配置，以指定应在Dependabot星期二 02：00 日本标准时间（UTC +09：00）检查 npm 依赖项的版本更新。

```yaml copy
# `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"
```

另请参阅[计划](/zh/code-security/reference/supply-chain-security/dependabot-options-reference#schedule-)。

### 为依赖项更新设置冷却期

可以使用 `cooldown` 选项的组合来控制何时 Dependabot 为 **版本更新**创建拉取请求，但不能使用 **安全更新**。

默认情况下，Dependabot 会对版本更新应用 3 天的冷却期，因此新版本在发布满 3 天之前不会被纳入版本更新考虑。
**此默认冷却不适用于安全更新。**

下面的 `dependabot.yml` 文件示例显示，冷却期适用于依赖项 `requests`、`numpy` 以及前缀为 `pandas` 或 `django` 的依赖项，但不适用于名为 `pandas` 的依赖项（精确匹配），该依赖项通过 exclude 列表被排除在外\*\*\*\*。

```yaml copy
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` 配合使用。

> \[!NOTE]
> 要将所有依赖项纳入冷却期考量，你可以\*\*\*\*：
>
> * 省略 `include` 选项，该选项会将冷却期应用于所有依赖项。
> * 在 `"*"` 中使用 `include`，以对所有项应用冷却期设置。
>   建议使用 `exclude` 来仅从冷却期设置中排除特定依赖项\*\*\*\*\*\*\*\*。

大多数包管理器都支持 SemVer。 处于冷却期的依赖项的新版本更新将被推迟，如下所示：

* 主要更新：延迟 30 天 (`semver-major-days: 30`)。
* 次要更新：延迟 7 天 (`semver-minor-days: 7`)。
* 补丁更新：延迟 3 天 (`semver-patch-days: 3`)。

另请参阅[`cooldown`](/zh/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-)。

## 优先处理有意义的更新

### 将相关依赖项组合在一起

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

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

* Dependabot 更新类型： `applies-to`
* 依赖项类型：`dependency-type`。
* 依赖项名称：`patterns` 和 `exclude-patterns`
* 语义版本控制级别：`update-types`

若要查看每个标准支持的所有值，请参阅[`groups`](/zh/code-security/reference/supply-chain-security/dependabot-options-reference#groups--)。

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

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

在本示例中，`dependabot.yml` 文件：

* 创建名为 `production-dependencies`、`development-dependencies` 和 `rubocop` 的三个组。
* 使用 `patterns` 和 `dependency-type` 将依赖项包含在组中。
* 使用 `exclude-patterns` 将一个（或多个）依赖项排除在组外。

```yaml
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`，分组仅适用于版本更新。

```yaml
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`，分组仅适用于版本更新。

```yaml
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` 版本更新。

```yaml
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`](/zh/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups)。

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

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