关于 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 Cloud 上运行。但是,Dependabot 打开的拉取请求可以触发运行操作的工作流。 有关详细信息,请参阅“通过 GitHub Actions 自动化 Dependabot”。
Dependabot 和所有相关功能均受许可协议约束。 有关详细信息,请参阅“GitHub 企业客户条款”。
Dependabot 拉取请求的频率
在配置文件中指定检查每个生态系统的新版本的频率:每日、每周或每月。
首次启用版本更新时,您可能有很多过时的依赖项,其中一些可能为许多落后于最新版本的版本。 Dependabot 将在其启用后立即检查过时的依赖项。 根据您配置更新的清单文件的数量,您可能会在添加配置文件后几分钟内看到新的版本更新拉取请求。 Dependabot 也会在配置文件后续更改时运行更新。
Dependabot 也可在更新失败后更改清单文件时创建拉取请求。 这是因为对清单的更改,例如删除导致更新失败的依赖项,可能会导致新触发的更新成功。
为使拉取请求保持可管理和易于审查,Dependabot 最多提出五个拉取请求,以便开始将依赖项更新至最新版本。 如果您在下次预定的更新之前先合并了这些拉取请求,剩余的拉取请求将在下次更新时打开,最多不超过此限。 可以通过设置open-pull-requests-limit
配置选项来更改打开的拉取请求的最大数量。
如果您启用了安全更新,有时会看到额外的安全更新拉取请求。 这些请求是由依赖于默认分支的 Dependabot 警报触发的。 Dependabot 自动提出拉取请求以更新有漏洞的依赖项。
支持的仓库和生态系统
您可以为包含其中一个受支持包管理器的依赖项清单或锁定文件的仓库配置版本更新。 对于某些软件包管理器,您也可以配置依赖项的供应。 有关详细信息,请参阅“dependabot.yml 文件的配置选项”。
注意:在运行安全性或版本更新时,有些生态系统必须能够解决来自其来源的所有依赖项,以验证版本更新是否成功。 如果清单或锁定文件包含任何私有依赖项,Dependabot 必须能够访问这些依赖项所在的位置。 组织所有者可以授予 Dependabot 访问包含同一个组织内项目依赖项的私有仓库. 有关详细信息,请参阅“管理组织的安全和分析设置”。 你可以在存储库的 dependabot.yml 配置文件中配置对专用注册表的访问。 有关详细信息,请参阅“dependabot.yml 文件的配置选项”。
Dependabot 不支持所有包管理器的私有 GitHub 依赖项。 详见下表。
下表对每个包管理器显示:
- 要在 dependabot.yml 文件中使用的 YAML 值
- 支持的包管理器版本
- 是否支持私有 GitHub 仓库或注册表中的依赖项
- 是否支持供应的依赖项
程序包管理器 | YAML 值 | 支持的版本 | 私有仓库 | 专用注册表 | 供应 |
---|---|---|---|---|---|
Bundler | bundler | v1, v2 | |||
Cargo | cargo | v1 | |||
编辑器 | composer | v1, v2 | |||
Docker [1] | docker | v1 | |||
Hex | mix | v1 | |||
elm-package | elm | v0.19 | |||
git submodule | gitsubmodule | 不适用 | |||
GitHub Actions [2] | github-actions | 不适用 | |||
Go 模块 | gomod | v1 | |||
Gradle [3] | gradle | 不适用 | |||
Maven [4] | maven | 不适用 | |||
npm | npm | v6、v7、v8 | |||
NuGet | nuget | <= 4.8 [5] | |||
pip [6] | pip | v21.1.2 | |||
pipenv | pip | <= 2021-05-29 | |||
pip-compile [6] | pip | 6.1.0 | |||
poetry | pip | v1 | |||
pub [7] | pub | v2 | |||
Terraform | terraform | >= 0.13、<= 1.3.x | |||
yarn | npm | V1、V2、V3 | [8] |
提示:对于包管理器(如 pipenv
和 poetry
),需要使用 pip
YAML 值。 例如,如果使用 poetry
来管理 Python 依赖项,并且希望让 Dependabot 监视新版本的依赖项清单文件,请在 dependabot.yml 文件中使用 package-ecosystem: "pip"
。
[1] Dependabot 可更新 Kubernetes 清单中的 Docker 映像标记。 对于包含引用 Docker 映像标记的 Kubernetes 清单的每个目录,请向 dependabot.yml 文件的 Docker package-ecosystem
元素添加一个条目。 Kubernetes 清单可以是 Kubernetes 部署 YAML 文件或 Helm 图表。 有关为 docker
配置 dependabot.yml 文件的信息,请参阅“dependabot.yml 文件的配置选项”中的“package-ecosystem
”。
Dependabot 支持公共和专用 Docker 注册表。 有关支持的注册表的列表,请参阅“dependabot.yml 文件的配置选项”中的“docker-registry
”。
[2] Dependabot 仅支持使用 GitHub 存储库语法(例如 actions/checkout@v3)更新 GitHub Actions。 目前不支持 Docker Hub 和 GitHub Packages Container registry URL。
[3] Dependabot 不运行 Gradle,但支持对以下文件的更新:
build.gradle
、build.gradle.kts
(适用于 Kotlin 项目)gradle/libs.versions.toml
(适用于使用标准 Gradle 版本目录的项目)- 通过
apply
声明包含的文件,文件名中包含dependencies
。 请注意,apply
不支持apply to
、递归或高级语法(例如,Kotlin 的apply
和mapOf
,由属性定义的文件名)。
[4] Dependabot 不运行 Maven,但支持对 pom.xml
文件的更新。
[5] Dependabot 不运行 NuGet CLI,但支持版本 4.8 及更早版本中的大多数功能。
[6] 除支持更新 requirements.txt
文件外,Dependabot 还支持更新 pyproject.toml
文件(如果它们遵循 PEP 621 标准)。
[7] Dependabot 在尝试更新到的版本被忽略时不会为 pub
执行更新,即使有可用的早期版本也是如此。
[8] Dependabot 支持 v2 及更高版本的 vendored 依赖项。
如果您的仓库已使用集成进行依赖项管理,则在启用 Dependabot 前需要禁用此集成。 有关详细信息,请参阅“关于集成”。
关于 Dependabot updates 的自动停用
当存储库的维护者停止与 Dependabot 拉取请求交互时,Dependabot 会暂时暂停其更新并发出通知。 这种自动选择退出行为可减少干扰,因为 Dependabot 不会对版本更新和安全更新创建拉取请求,也不会对非活动存储库的 Dependabot 拉取请求进行变基。
Dependabot 更新的自动停用仅适用于符合以下条件的存储库:Dependabot 已打开拉取请求但拉取请求保持不变。 如果 Dependabot 尚未打开任何拉取请求,Dependabot 将永远不会暂停。
活动存储库是指用户(非 Dependabot)在过去 90 天内执行了以下任一操作的存储库:
- 在存储库上合并或关闭 Dependabot 拉取请求。
- 对存储库的 dependabot.yml 文件进行更改。
- 手动触发安全更新或版本更新。
- 为存储库启用 Dependabot security updates。
- 对拉取请求使用
@dependabot
命令。
非活动存储库是指以下存储库:至少有一个 Dependabot 拉取请求打开时间超过 90 天,在整个期间处于启用状态,并且用户未执行上面列出的任何操作。
暂停 Dependabot 时,GitHub 会将通知添加到所有打开的 Dependabot 拉取请求的正文中,并为这些拉取请求分配 dependabot-paused
标签。 存储库的“设置”选项卡的 UI 中会显示一条横幅通知(在“代码安全和分析”下的 Dependabot 中),Dependabot alerts 列表也会显示该通知(如果 Dependabot security updates 受到影响) 。
维护人员再次与 Dependabot 拉取请求交互后,Dependabot 将自行取消暂停:
- Dependabot alerts 的安全更新将会自动恢复。
- 版本更新将按照 dependabot.yml 文件中指定的计划自动恢复。
关于 Dependabot 版本更新通知
您可以按 GitHub 筛选通知,以显示由 Dependabot创建的拉取请求的通知。 有关详细信息,请参阅“从收件箱管理通知”。