关于 Dependabot 版本更新

Dependabot 消除了维护依赖项的麻烦。您可以使用它来确保您的存储库自动保持与其依赖的软件包和应用程序的最新版本同步。

有关受支持的存储库和生态系统的更多信息，请参阅“Dependabot 支持的生态系统和存储库”。

您可以通过将dependabot.yml配置文件检入您的存储库来启用 Dependabot 版本更新。配置文件指定存储在您存储库中的清单或其他包定义文件的位置。Dependabot 使用此信息来检查过时的软件包和应用程序。Dependabot 通过查看依赖项的语义版本控制 (semver) 来确定是否存在新版本的依赖项，以决定是否应该更新到该版本。对于某些包管理器，Dependabot 版本更新还支持供应商管理。供应商管理（或缓存）的依赖项是指检入存储库中特定目录的依赖项，而不是在清单中引用。即使包服务器不可用，供应商管理的依赖项也可以在构建时使用。可以将 Dependabot 版本更新配置为检查供应商管理的依赖项的新版本，并在必要时更新它们。

当 Dependabot 识别出过时的依赖项时，它会发出一个 pull request 来将清单更新到依赖项的最新版本。对于供应商管理的依赖项，Dependabot 会发出一个 pull request 来直接将过时的依赖项替换为新版本。您可以检查测试是否通过，查看 pull request 摘要中包含的更改日志和发行说明，然后合并它。有关更多信息，请参阅“配置 Dependabot 版本更新”。

如果您启用了安全更新，Dependabot 还会发出 pull request 来更新存在漏洞的依赖项。有关更多信息，请参阅“关于 Dependabot 安全更新”。

当 Dependabot 发出 pull request 时，这些 pull request 可能是安全或版本更新。

Dependabot 安全更新是自动 pull request，可帮助您更新已知存在漏洞的依赖项。
Dependabot 版本更新是自动 pull request，即使依赖项没有任何漏洞，也会使您的依赖项保持最新。要检查版本更新的状态，请导航到存储库的“Insights”选项卡，然后是“依赖关系图”和“Dependabot”。

Dependabot 默认情况下会签署其自己的提交，即使存储库不需要提交签署也是如此。有关已验证提交的更多信息，请参阅“关于提交签名验证”。

Dependabot 打开的 pull request 可以触发运行 Actions 的工作流。有关更多信息，请参阅“使用 GitHub Actions 自动化 Dependabot”。

如果您在新存储库上启用 Dependabot 并启用了 GitHub Actions，Dependabot 将默认在 GitHub Actions 上运行。

如果您在一个新的仓库中启用 Dependabot，并且禁用了 GitHub Actions，Dependabot 将在 GitHub 的旧版应用程序上运行以执行 Dependabot 更新。这不如 GitHub Actions 提供的 Dependabot 更新作业性能、可见性或控制好。如果您想将 Dependabot 与 GitHub Actions 一起使用，则必须确保您的仓库启用了 GitHub Actions，然后从仓库的“代码安全和分析”设置页面启用“Actions 运行器上的 Dependabot”。更多信息，请参阅“关于 GitHub Actions 运行器上的 Dependabot”。

Dependabot 及其所有相关功能均受GitHub 服务条款的约束。

Dependabot 拉取请求的频率

您可以在配置文件中指定多久检查每个生态系统的新版本：每日、每周或每月。

首次启用版本更新时，您可能有很多过时的依赖项，有些依赖项可能落后于最新版本多个版本。启用 Dependabot 后，它会立即检查过时的依赖项。根据您配置更新的清单文件数量，您可能会在添加配置文件后的几分钟内看到用于版本更新的新拉取请求。Dependabot 还将在配置文件的后续更改时运行更新。

为了使拉取请求易于管理和审查，Dependabot 最多会发出五个拉取请求以开始将依赖项更新到最新版本。如果您在下次计划更新之前合并了其中一些初始拉取请求，则剩余的拉取请求将在下次更新时打开，最多达到该最大值。您可以通过设置open-pull-requests-limit 配置选项来更改打开的拉取请求的最大数量。

为了进一步减少您可能看到的拉取请求数量，您可以使用groups配置选项将一组依赖项组合在一起（每个包生态系统）。然后，Dependabot 将发出单个拉取请求，以同时将组中尽可能多的依赖项更新到最新版本。更多信息，请参阅“自定义依赖项更新”。

如果您已启用安全更新，有时您会看到针对安全更新的额外拉取请求。这些是由针对默认分支上依赖项的 Dependabot 警报触发的。Dependabot 会自动发出拉取请求以更新易受攻击的依赖项。

有时，由于配置错误或不兼容的版本，您可能会发现 Dependabot 运行失败了。在 15 次运行失败后，Dependabot 版本更新将跳过后续的计划运行，直到您从依赖关系图手动触发更新检查为止。Dependabot 安全更新仍将照常运行。

关于 Dependabot 更新的自动停用

当仓库维护者停止与 Dependabot 拉取请求交互时，Dependabot 会暂时暂停其更新并通知您。这种自动选择退出行为减少了噪音，因为 Dependabot 不会为版本和安全更新创建拉取请求，也不会为非活动仓库重新设置 Dependabot 拉取请求的基础。

Dependabot 更新的自动停用仅适用于 Dependabot 已打开拉取请求但拉取请求保持未触碰的仓库。如果 Dependabot 没有打开任何拉取请求，Dependabot 将永远不会暂停。

活动仓库是指在过去 90 天内用户（非 Dependabot）已执行以下任何操作的仓库

合并或关闭仓库上的 Dependabot 拉取请求。
更改仓库的dependabot.yml文件。
手动触发安全更新或版本更新。
为仓库启用 Dependabot 安全更新。
在拉取请求上使用@dependabot命令。

非活动仓库是指至少有一个 Dependabot 拉取请求已打开超过 90 天、已启用整个期间且用户未执行上述任何操作的仓库。

Dependabot 暂停时，GitHub 会添加横幅通知

到所有打开的 Dependabot 拉取请求。
到仓库的**设置**选项卡的 UI（在**代码安全和分析**下，然后是**Dependabot**）。
到 Dependabot 警报列表（如果 Dependabot 安全更新受到影响）。

维护者再次与 Dependabot 拉取请求交互后，Dependabot 将自行恢复暂停。

安全更新会自动恢复 Dependabot 警报。
版本更新将根据dependabot.yml文件中指定的计划自动恢复。

Dependabot 还将在 30 天后停止为版本和安全更新重新设置拉取请求的基础，从而减少非活动 Dependabot 拉取请求的通知。