注意：站点管理员必须先为 你的 GitHub Enterprise Server 实例设置 Dependabot updates，然后你才能使用此功能。 有关详细信息，请参阅“为企业启用 Dependabot”。
关于 Dependabot version updates
Dependabot 负责维护您的依赖项。 您可以使用它来确保仓库自动跟上它所依赖的包和应用程序的最新版本。
通过将 dependabot.yml 配置文件签入存储库，可启用 Dependabot version updates。 配置文件指定存储在仓库中的清单或其他包定义文件的位置。 Dependabot 使用此信息检查过时的包和应用程序。 Dependabot 通过查看依赖项的语义版本控制 (semver) 来确定是否存在新版本的依赖项，从而决定它是否应该更新到该版本。 对于某些软件包管理器，Dependabot version updates 也支持供应。 供应（或缓存）的依赖项是检入仓库中特定目录的依赖项，而不是在清单中引用的依赖项。 即使包服务器不可用，供应的依赖项在生成时也可用。 Dependabot version updates 可以配置为检查为新版本供应的依赖项，并在必要时更新它们。
当 Dependabot 发现过时的依赖项时，它将引发一个拉取请求，用于将清单更新到依赖项的最新版本。 对于供应和依赖项，Dependabot 提出拉取请求以直接将过时的依赖项替换为新版本。 检查测试是否通过，查看拉取请求摘要中包含的更改日志和发行说明，然后合并它。 有关详细信息，请参阅“配置 Dependabot 版本更新”。
如果启用“安全更新”，Dependabot 还将引发用于更新易受攻击的依赖项的拉取请求。 有关详细信息，请参阅“关于 Dependabot 安全更新”。
当 Dependabot 提出拉取请求时，这些拉取请求可以是安全更新或版本更新：
- Dependabot security updates 是自动拉取请求，可帮助你更新已知漏洞的信赖项。
- Dependabot version updates 是自动拉取请求，即使它们没有任何漏洞，也会保持更新依赖项。 要检查版本更新的状态，请依次导航到仓库的 Insights（见解）选项卡、Dependency Graph（依赖关系图）、Dependabot。
GitHub Actions 为 ，Dependabot version updates 和 Dependabot security updates 在 GitHub Enterprise Server 上运行。 启用 Dependabot updates 之前，必须配置 你的 GitHub Enterprise Server 实例 以使用具有自托管运行器的 GitHub Actions。有关详细信息，请参阅“为企业启用 Dependabot”。
Dependabot 拉取请求的频率
在配置文件中指定检查每个生态系统的新版本的频率：每日、每周或每月。
首次启用版本更新时，您可能有很多过时的依赖项，其中一些可能为许多落后于最新版本的版本。 Dependabot 将在其启用后立即检查过时的依赖项。 根据您配置更新的清单文件的数量，您可能会在添加配置文件后几分钟内看到新的版本更新拉取请求。 Dependabot 也会在配置文件后续更改时运行更新。
Dependabot 也可在更新失败后更改清单文件时创建拉取请求。 这是因为对清单的更改，例如删除导致更新失败的依赖项，可能会导致新触发的更新成功。
为使拉取请求保持可管理和易于审查，Dependabot 最多提出五个拉取请求，以便开始将依赖项更新至最新版本。 如果您在下次预定的更新之前先合并了这些拉取请求，剩余的拉取请求将在下次更新时打开，最多不超过此限。 可以通过设置open-pull-requests-limit配置选项来更改打开的拉取请求的最大数量。
如果您启用了安全更新，有时会看到额外的安全更新拉取请求。 这些请求是由依赖于默认分支的 Dependabot 警报触发的。 Dependabot 自动提出拉取请求以更新有漏洞的依赖项。
支持的仓库和生态系统
您可以为包含其中一个受支持包管理器的依赖项清单或锁定文件的仓库配置版本更新。 对于某些软件包管理器，您也可以配置依赖项的供应。 有关详细信息，请参阅“dependabot.yml 文件的配置选项”。
注意：为确保 GitHub Enterprise Server 支持最新受支持的生态系统版本的 Dependabot updates，企业所有者必须下载最新版本的 Dependabot 操作。 有关操作的详细信息，以及如何下载最新版本的说明，请参阅“使用官方捆绑操作的最新版本”。
注意：在运行安全性或版本更新时，有些生态系统必须能够解决来自其来源的所有依赖项，以验证版本更新是否成功。 如果清单或锁定文件包含任何私有依赖项，Dependabot 必须能够访问这些依赖项所在的位置。 组织所有者可以授予 Dependabot 访问包含同一个组织内项目依赖项的私有仓库. 有关详细信息，请参阅“管理组织的安全和分析设置”。 你可以在存储库的 dependabot.yml 配置文件中配置对专用注册表的访问。 有关详细信息，请参阅“dependabot.yml 文件的配置选项”。
Dependabot 不支持所有包管理器的私有 GitHub 依赖项。 详见下表。
下表对每个包管理器显示：
- 要在 dependabot.yml 文件中使用的 YAML 值
- 支持的包管理器版本
- 是否支持私有 GitHub 仓库或注册表中的依赖项
- 是否支持供应的依赖项
| 程序包管理器 | YAML 值 | 支持的版本 | 私有仓库 | 专用注册表 | 供应 |
|---|---|---|---|---|---|
| Bundler | bundler | v1, v2 | ✓ | ✓ | |
| Cargo | cargo | v1 | ✓ | ✓ | |
| 编辑器 | composer | v1, v2 | ✓ | ✓ | |
| Docker | docker | v1 | ✓ | ✓ | |
| Hex | mix | v1 | ✓ | ||
| elm-package | elm | v0.19 | ✓ | ✓ | |
| git submodule | gitsubmodule | N/A（无版本） | ✓ | ✓ | |
| GitHub Actions [2] | github-actions | N/A（无版本） | ✓ | ✓ | |
| Go 模块 | gomod | v1 | ✓ | ✓ | ✓ |
| Gradle [3] | gradle | N/A（无版本） | ✓ | ✓ | |
| Maven [4] | maven | N/A（无版本） | ✓ | ✓ | |
| npm | npm | v6、v7、v8 | ✓ | ✓ | |
| NuGet | nuget | <= 4.8 [5] | ✓ | ✓ | |
| pip | pip | v21.1.2 | ✓ | ||
| pipenv | pip | <= 2021-05-29 | ✓ | ||
| pip-compile | pip | 6.1.0 | ✓ | ||
| poetry | pip | v1 | ✓ | ||
| pub [7] | pub | v2 | |||
| Terraform | terraform | >= 0.13、<= 1.3.x | ✓ | ✓ | |
| yarn | npm | v1 | ✓ | ✓ |
提示：对于包管理器（如 pipenv 和 poetry），需要使用 pip YAML 值。 例如，如果使用 poetry 来管理 Python 依赖项，并且希望让 Dependabot 监视新版本的依赖项清单文件，请在 dependabot.yml 文件中使用 package-ecosystem: "pip"。
[2] Dependabot 仅支持使用 GitHub 存储库语法（例如 actions/checkout@v3）更新 GitHub Actions。 目前不支持 Docker Hub 和 GitHub Packages Container registry URL。
[3] Dependabot 不运行 Gradle，但支持对以下文件的更新：build.gradle、build.gradle.kts（针对 Kotlin 项目），以及通过 apply 声明包含在内且文件名中带有 dependencies 的文件。 请注意，apply 不支持 apply to、递归或高级语法（例如，Kotlin 的 apply 和 mapOf，由属性定义的文件名）。
[4] Dependabot 不运行 Maven，但支持对 pom.xml 文件的更新。
[5] Dependabot 不运行 NuGet CLI，但支持版本 4.8 及更早版本中的大多数功能。
[7] Dependabot 在尝试更新到的版本被忽略时不会为 pub 执行更新，即使有可用的早期版本也是如此。
如果您的仓库已使用集成进行依赖项管理，则在启用 Dependabot 前需要禁用此集成。
关于 Dependabot 版本更新通知
您可以按 GitHub 筛选通知，以显示由 Dependabot创建的拉取请求的通知。 有关详细信息，请参阅“从收件箱管理通知”。