Tame Dependabot: Group your updates, slow the cadence, keep security fast

如果你维护着一个活跃的代码仓库，一定经历过这种场景。周一早上打开通知，映入眼帘的是五条、十条，甚至十二条Dependabot拉取请求，每条都只更新单个依赖项的单个补丁版本。单独来看，每条更新都有价值。但整体而言，它们只是噪音。而噪音正是导致重要更新被忽视的元凶。

我们分析了微软的GCToolkit项目，这是一个用于分析垃圾回收日志的开源Java库。截至2026年7月，该仓库的git log显示：578个提交中有92个（约占六分之一）是Dependabot的版本更新，仅过去12个月就有61次更新，有时甚至一天内出现多次。这意味大量代码审查、合并和CI流程都耗费在了日常维护上。

好消息是：Dependabot已经内置了修复此问题的功能。在最近的拉取请求中，该项目通过三个细微但关键的修改，将原本每天产生的单依赖项拉取请求，转化为按生态系统划分的每月批量更新。以下是具体修改内容、原理说明，以及如何参照GCToolkit的方案应用到你的仓库中。

问题：良好的默认配置，错误的更新节奏

修改前GCToolkit的配置如下：

version: 2
updates:
- package-ecosystem: github-actions
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 10

这是一个常见起点，但此处的daily间隔是刻意选择而非默认值：schedule.interval是必填项，GitHub的建议初始模板使用的是weekly。导致此配置产生噪音的两个因素是：

• `interval: daily` 指令Dependabot在每个工作日（周一至周五）检查更新。对于引用少量GitHub Actions的仓库，这意味着任何工作日都可能出现新拉取请求。
• 未启用分组 导致每个依赖项都生成独立的拉取请求。若有10个可用更新，就会产生10个拉取请求、10次CI运行和10条审查通知。

open-pull-requests-limit: 10只是症状而非解决方案：它将同时打开的拉取请求数限制为10个，但无法阻止拉取请求的持续产生。

解决方案：三个相辅相成的改进

修改后的配置如下：

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"
    groups:
      monthly-batch:
        patterns:
          - "*"

  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "monthly"
    groups:
      monthly-batch:
        patterns:
          - "*"

此处发生了三个相辅相成的改变：

1. 将所有更新合并为单个拉取请求

groups块是此次修改的核心：

groups:
  monthly-batch:
    patterns:
      - "*"

Dependabot组 可将多个依赖项更新合并到一个拉取请求中。组名（monthly-batch）由您自定义，会显示在拉取请求标题和分支名称中。patterns 列表决定哪些依赖项属于该组，"*" 是通配符，可匹配所有依赖项。

这样您将获得一个标题类似 _“将 monthly-batch 组更新 10 次”_ 的拉取请求。一个分支。一次 CI 运行。一次代码审查。如果整个批次通过测试，您只需合并一次即可完成。如果出现错误，所有问题都会被限制在一个可审查的单一位置。

对于大型项目，您无需将所有内容合并在一起。可以定义多个具有更具体模式的命名组。例如，您可以将所有测试库放在一个组中，将生产依赖项放在另一个组中，使相关更新一起移动，无关更新保持独立。

分组功能也在不断增强。在 2026 年 2 月更新 中，Dependabot 增加了按依赖项名称跨多个目录进行分组的功能。这一功能专门针对单体仓库：如果某个库在十几个服务中被固定版本，以前每次更新都会在每个目录中生成十几个几乎相同的拉取请求。现在您可以将 directories 键（注意复数形式）指向一个路径列表，或使用类似 /apps/* 的通配符，让您的组将所有内容合并为一个：

- package-ecosystem: "npm"
  directories:
    - "/apps/*"
  schedule:
    interval: "monthly"
  groups:
    monthly-batch:
      group-by: dependency-name
      patterns:Expand comment
        - "*"

这与之前的 monthly-batch 组相同，但现在覆盖仓库中的每个服务，而不仅仅是单个目录。如需查看所有选项，请参阅 Dependabot 选项参考。

2. 将更新频率从每日调整为每月

schedule:
  interval: "monthly"

将 daily 改为 monthly 可将更新节奏从“任何更改时立即触发”调整为“按您可规划的计划每月一次”。结合分组功能，这能真正减少噪音：Dependabot 现在每月每个生态系统只生成 一个 批量拉取请求，而不是整月持续不断的小更新。

对于依赖项稳定且更新不紧急的成熟库，选择每月更新是更合适的做法。如果您需要介于两者之间的频率，也可以使用 weekly，并通过 schedule.day 和 schedule.time 指定具体日期和时间。

3. 覆盖所有实际使用的生态系统

原始配置仅请求了 github-actions 的版本更新。但 GCToolkit 是一个使用 Maven 构建的 Java 项目，因此其应用依赖项未收到 Dependabot 的版本更新。更新后的配置添加了第二个 updates 条目：

- package-ecosystem: "maven"
  directory: "/"

这是一个容易被忽略的点。减少噪音只是全部收益的一半；另一半是确保 Dependabot 在关注最重要的依赖项。每个生态系统都有自己的计划和分组，因此您的 Actions 更新和 Maven 更新会作为两个清晰独立的批次到达。

但安全更新又该如何处理？

这是每个维护者在放慢更新节奏前都应该提出的问题，而这一设计正是其亮点所在：默认情况下，你在此处设置的组别和计划决定了版本更新的节奏，而非安全补丁的处理方式。

Dependabot 安全更新会在漏洞修复方案公开后立即触发，与你的 schedule 设置无关，也独立于版本更新组别。因此，即使你为常规更新设置了每月批量处理的节奏，也不会延迟关键补丁的推送。（你确实可以通过将组别限定为 applies-to: security-updates 的方式，主动对安全补丁进行批量处理，但即便如此，这些补丁的触发仍基于漏洞披露，而非版本更新计划。）

需要注意的一点是：这个“安全网”只有在仓库确实启用了 Dependabot 安全更新时才有效，而这也要求依赖图谱和 Dependabot 告警功能必须处于启用状态。在依赖更慢的版本更新节奏前，请务必确认这些功能已开启。做到这一点，你将获得两全其美的效果：常规维护工作安静且可预测，而当真实漏洞出现时，又能立即采取行动。

这种分离机制正是“放慢 Dependabot”成为安全建议而非风险操作的关键所在。

新增的安全保障：默认包冷却机制

还有一个最近新增的降噪功能，它会自动生效。Dependabot 现在会在新版本发布后等待至少 三天，才会为新版本创建更新请求。这个 _冷却机制_ 是默认启用的，无需任何配置。

为什么要等待？全新发布的版本是供应链攻击最常见的入口点之一。在维护者和社区发现版本问题前，被入侵或存在缺陷的版本就可能被纳入依赖更新。短暂的延迟可以让问题暴露的信号有时间显现，从而大幅降低你刚发布就立即合并有缺陷版本的风险。

有两件事情需要特别注意：

• 仅适用于版本更新。 安全更新仍会立即触发，因此关键修复从不会因冷却机制而被延迟。
• 你仍保有控制权。 通过在 .github/dependabot.yml 中使用 `cooldown` 选项，你可以扩大或缩短冷却窗口、按语义化版本级别进行调整，甚至完全禁用该功能：

- package-ecosystem: "maven"
  directory: "/"
  schedule:
    interval: "monthly"
  cooldown:
    default-days: 7
  groups:
    monthly-batch:
      patterns:
        - "*"

将冷却机制与分组功能和月度节奏结合使用时，效果会叠加：拉取请求数量减少，而你收到的每个请求都已经过几天的验证，证明其可以安全合并。

1. 在仓库的默认分支中打开（或创建）.github/dependabot.yml文件。
2. 对于您依赖的每个 package-ecosystem，将 schedule.interval 设置为 weekly 或 monthly。
3. 添加一个 groups 块，包含一个通配符组（patterns: ["*"]），将更新合并为每个生态系统一个拉取请求。
4. 确保列出您实际使用的每个生态系统：不仅仅是 github-actions，还包括 maven、npm、pip、gomod、docker 等。
5. 提交更改，让下一次计划任务生成一个按生态系统分组的拉取请求。

调整配置时的一些提示：

• 先广泛再细分。 一个通配符组是最简单的起点。如果您之后发现需要对补丁级别和主要版本更新进行不同处理，可以将通配符拆分为更具体的命名组。
• 不要将安全修复纳入此节奏。 Dependabot 的安全更新由漏洞披露触发，而非您的版本更新计划，因此每月节奏不会延迟它们。您甚至可以通过 applies-to: security-updates 将其分组，而不会影响处理速度。
• 利用冷却期机制。 默认的三天冷却期已能保护您免受新发布的恶意版本影响；如果需要更宽的安全边际，可以增加 cooldown.default-days 的值。
• 合理设置更新间隔。 快速迭代的应用可能更适合 weekly，而稳定的库使用 monthly 即可。
• 合并单体仓库目录。 如果同一依赖项存在于多个目录中，请在 directories 下列出它们，并在组中设置 group-by: dependency-name，这样一次版本升级只会生成一个拉取请求，而非每个目录一个。

总结

依赖项更新是一项容易自动化却可能被忽视的任务，这反而违背了初衷。解决问题的方法不是关闭 Dependabot 或盲目合并拉取请求，而是调整其输出，使常规工作安静且批量处理，而紧急任务仍能突出显示。

GCToolkit 通过大约十几行 YAML 配置实现了这一点：将所有内容分组、将节奏放缓至每月，并确保覆盖每个生态系统。再加上新的默认冷却期配置，即使每月批量更新也会在到达您之前有几天时间验证自身安全性。最终结果是更少的拉取请求、更少的 CI 运行，最重要的是，审查队列中真正重要的更新不会被无关的更新淹没。

进一步阅读： 当常规拉取请求的噪音被控制后，更困难的问题是优先处理哪些安全警报。我们之前的博文《穿透噪音：如何优先处理 Dependabot 警报》介绍了如何利用 EPSS 分数和仓库属性，将庞大的警报列表转化为清晰的风险排序队列。

• * *

标签：

• Dependabot
• GitHub Actions
• 开源
• 供应链安全

作者

高级产品经理

探索更多 GitHub 内容

文档

掌握 GitHub 所需的一切，尽在一处。

前往文档

GitHub

在 GitHub 上构建未来，这里是任何人都可以来自任何地方构建任何事物的地方。

立即开始构建

客户案例

了解使用 GitHub 构建产品的公司和工程团队。

了解更多

GitHub Universe 2026

10月28日至29日，加入我们在旧金山或在线参加 GitHub Universe——我们的旗舰开发者大会，汇聚全球开发者、代理和代码。

立即注册