当 Dependabot 在更新依赖时遇到错误，你可以使用本参考文档诊断并修复常见问题。
如何查看错误
安全更新错误
当 Dependabot 因被阻止而无法创建拉取请求来修复 Dependabot 警报时，它会在警报上发布错误信息。Dependabot 警报视图会列出所有尚未解决的警报。要访问警报视图，请在仓库的 安全与质量选项卡。若已生成用于修复漏洞依赖的拉取请求，则警报会包含指向该拉取请求的链接。
警报可能因多种原因没有拉取请求链接
- 未为仓库启用 Dependabot 安全更新。
- 该警报对应的是未在锁定文件中显式定义的间接或传递依赖。
- 错误导致 Dependabot 无法创建拉取请求。
要查看错误详情，请点击该警报。
版本更新错误
当 Dependabot 在某个生态系统中被阻止创建拉取请求以更新依赖时，你可以查看作业日志列表以了解更多错误信息。
作业日志列表可从仓库的依赖图访问。在依赖图中，点击 Dependabot 选项卡，然后在受影响的清单文件右侧，点击 Recent update jobs（近期更新作业）。
要查看特定作业的完整日志文件，在感兴趣的日志条目右侧，点击 view logs。
更多信息，请参阅 查看 Dependabot 作业日志。
依赖解析错误
无法将 DEPENDENCY 更新为非漏洞版本
适用范围：仅限安全更新
错误信息： Dependabot cannot update DEPENDENCY to a non-vulnerable version
Dependabot 无法创建拉取请求，将易受攻击的依赖升级到安全版本，而不会破坏此仓库的依赖图中的其他依赖。
每个包含依赖的应用都有一张依赖图，即该应用直接或间接依赖的每个软件包版本的有向无环图。每次更新依赖时，都必须重新解析该图，否则应用将无法构建。当生态系统（如 npm、RubyGems）拥有深且复杂的依赖图时，往往无法仅升级单个依赖而不升级整个生态系统。
解决方案：保持使用最近发布的版本，例如通过启用版本更新。这会提高通过一次简单升级即可修复单个依赖漏洞而不破坏依赖图的几率。参见 配置 Dependabot 版本更新。
更新没有警报的依赖项
适用范围：仅限安全更新
错误信息： Dependabot tries to update dependencies without an alert
Dependabot 会为所有生态系统更新显式定义的易受攻击的传递依赖。对于 npm，若唯一的修复方式是更新父依赖，Dependabot 将在同一个拉取请求中同时更新父依赖。
例如，项目依赖 A 版本 ~2.0.0，而 A 具有传递依赖 B 版本 ~1.0.0，该版本解析为 1.0.1。
my project
|
--> A (2.0.0) [~2.0.0]
|
--> B (1.0.1) [~1.0.0]
如果 B 版本 <2.0.0 存在安全漏洞且已在 2.0.0 发布补丁，Dependabot 会尝试更新 B，但会因 A 的限制只能使用低版本而失败。为修复漏洞，Dependabot 会寻找能够允许使用已修复的 B 版本的 A 更新。
Dependabot 会自动生成一个拉取请求，升级已锁定的父依赖和子传递依赖。
无法关闭已应用更新的拉取请求
错误信息： Dependabot fails to close a open pull request for an update that has already been applied on the default branch
Dependabot 会在检测到更新已提交到默认分支后关闭相应的拉取请求。但在极少数情况下，拉取请求可能仍保持打开状态。
解决方案：如果你手动提交了依赖更新且对应的拉取请求仍然打开，可在该拉取请求的评论中使用以下任意命令：
@dependabot recreate，或@dependabot rebase.
任一评论都会触发 Dependabot 检查该依赖是否仍可升级或仍有漏洞。如果 Detectabot 判断不再需要该拉取请求，它将关闭该拉取请求。
有关 Dependabot 评论命令的更多信息，请参阅 管理依赖更新的拉取请求。
无法更新到所需版本，因为已经有一个打开的最新版本拉取请求
适用范围：仅限安全更新
错误信息： Dependabot cannot update to the required version as there is already an open pull request for the latest version
Dependabot 不会创建新的拉取请求来升级易受攻击的依赖，因为已经存在一个用于更新该依赖的打开拉取请求。当检测到单个依赖的漏洞且已有另一个拉取请求在更新到最新版本时，就会出现此错误。
解决方案：审查该打开的拉取请求，确认更改安全后尽快合并，或关闭该拉取请求并手动触发新的安全更新拉取请求。参见 手动触发 Dependabot 拉取请求。
无需安全更新
适用范围：仅限安全更新
错误信息： No security update is needed as DEPENDENCY is no longer vulnerable
Dependabot 无法关闭已更新但不再或从未有漏洞的依赖的拉取请求。当依赖图数据过时，或依赖图与 Dependabot 对某个版本是否有漏洞的判断不一致时，可能会看到此错误。
解决方案：首先检查仓库的依赖图，确认其检测到的依赖版本，并核实该版本是否与仓库实际使用的版本匹配。
如果怀疑依赖图数据已过期，可能需要手动更新仓库的依赖图或进一步调查依赖信息。参见 依赖图故障排查。
如果确认该依赖版本已不再存在漏洞，可关闭 Dependabot 的拉取请求。
拉取请求错误
已达到拉取请求上限
错误信息： Dependabot cannot open any more pull requests
Dependabot 能生成的打开拉取请求数量有限。当达到此上限时，将不再打开新拉取请求，并报告此错误。
限制
- 安全更新拉取请求：10
- 版本更新拉取请求：5（可通过
open-pull-requests-limit配置）
安全更新和版本更新各有独立的上限，确保版本更新的打开拉取请求不会阻塞安全更新的创建。更多信息请参阅 Dependabot 选项参考。
解决方案：合并或关闭部分现有拉取请求，然后手动触发新的拉取请求。参见 手动触发 Dependabot 拉取请求。
超时和性能错误
更新超时
错误信息： Dependabot timed out during its update
Dependabot 在评估所需更新并准备拉取请求时耗时超过最大允许时间。此错误通常只会在拥有大量清单文件的大型仓库（例如拥有数百个 package.json 的 npm 或 yarn 单体仓库）中出现。Composer 生态系统的更新也可能耗时更长并出现超时。
版本更新的解决方案：使用 allow 参数指定最重要的依赖进行更新，或使用 ignore 参数排除部分依赖。调整配置后，Dependabot 可能在可用时间内完成版本更新并生成拉取请求。
安全更新的解决方案：通过保持依赖最新（例如启用版本更新）来降低超时概率。更多信息请参阅 配置 Dependabot 版本更新。
分组错误
未能分组依赖（版本更新）
适用范围：仅限版本更新
错误信息： Dependabot fails to group a set of dependencies into a single pull request for Dependabot version updates
groups 配置可在 dependabot.yml 文件中用于版本更新和安全更新。使用 applies-to 键指定该分组规则适用于版本更新还是安全更新。
不能同时将同一套分组规则应用于 版本 更新和 安全 更新。若想使用相同标准对两者进行分组，则必须定义两个分别命名的分组规则集合。
配置分组的版本更新时，需要按每个包生态系统分别配置分组。
常见原因 - 空分组：可能无意中创建了空分组。例如，在 allow 键中为整体作业设置了 dependency-type，导致分组为空。
allow:
dependency-type: production
# this restricts the entire job to production dependencies
groups:
development-dependencies:
dependency-type: "development"
# this group will always be empty
allow:
dependency-type: production
# this restricts the entire job to production dependencies
groups:
development-dependencies:
dependency-type: "development"
# this group will always be empty
在此示例中，Dependabot 将会
- 查看你的依赖列表，并将作业限制为仅使用
production环境的依赖。 - 尝试创建一个名为
development-dependencies的分组，它是上述受限列表的子集。 - 结果发现
development-dependencies分组为空，因为在第 1 步中已将所有development依赖删除。 - 单独 更新不在该分组中的所有依赖。由于生产环境的分组为空，Dependabot 会忽略该分组，并为每个剩余依赖单独创建拉取请求。
解决方案：确保配置设置之间不会相互抵消，并在 dependabot.yml 中相应地更新它们。若需调试，请查看日志。有关获取清单日志的信息，请参阅 如何查看错误。
有关如何为 Dependabot 版本更新配置分组的更多信息，请参阅 Dependabot 选项参考。
未能分组依赖（安全更新）
适用范围：仅限安全更新
错误信息： Dependabot fails to group a set of dependencies into a single pull request for Dependabot security updates
groups 配置可在 dependabot.yml 文件中用于版本更新和安全更新。使用 applies-to 键指定规则适用于版本更新还是安全更新。请确保已对安全更新配置分组。如果在配置中缺少 applies-to 键，则默认仅对版本更新生效。
不能同时将同一套分组规则应用于 版本 更新和 安全 更新。若想使用相同标准对两者进行分组，则必须定义两个分别命名的分组规则集合。
安全更新的分组指南
- 当在使用
directories键的配置中指定分组规则时，Dependabot 会 将同一包生态系统下位于不同目录的依赖进行分组。 - Dependabot 会 将
dependabot.yml中的其他相关自定义选项应用到分组安全更新的拉取请求。文件中的分组规则会覆盖组织或仓库层面启用/禁用分组安全更新的 UI 设置。 - Dependabot 不会 将不同包生态系统的依赖合并分组。
- Dependabot 不会 将安全更新与版本更新合并分组。
更多信息请参阅 关于 Dependabot 安全更新的分组 与 自定义 Dependabot 安全更新的拉取请求。
未能在分组拉取请求中更新依赖
错误信息： Dependabot fails to update one of the dependencies in a grouped pull request
针对失败的版本更新和失败的安全更新有不同的故障排查方法。
版本更新
适用范围：仅限版本更新
Dependabot 会在日志以及日志末尾的作业摘要中显示失败的更新。
解决方案
- 在该拉取请求中使用
@dependabot recreate评论重新构建分组。参见 管理依赖更新的拉取请求。 - 如果依赖仍然更新失败，可使用
exclude-patterns配置将其排除出分组。Dependabot 将随后为该依赖单独创建拉取请求。 - 如果依赖仍然更新失败，可能是该依赖本身出现问题，或该生态系统的 Dependabot 存在问题。
若想忽略该依赖的更新，需要执行以下任一操作。
- 在
dependabot.yml文件中为该依赖配置ignore规则。更多信息请参阅 Dependabot 选项参考。 - 在分组更新的拉取请求中，对该依赖使用
@dependabot ignore评论命令。更多信息请参阅 管理分组更新的拉取请求。
安全更新
适用范围：仅限安全更新
如果分组的安全更新拉取请求失败或无法合并，手动打开拉取请求以提升破坏性变更的版本。当你手动更新了分组拉取请求中包含的包时，Dependabot 会重新基准该拉取请求，以避免包含已手动更新的包。
若想忽略该依赖的更新，需要执行以下任一操作。
- 在
dependabot.yml文件中为该依赖配置ignore规则。更多信息请参阅 Dependabot 选项参考。 - 在分组更新的拉取请求中，对该依赖使用
@dependabot ignore评论命令。更多信息请参阅 管理分组更新的拉取请求。
持续集成在分组拉取请求上失败
适用范围：仅限版本更新
错误信息： Continuous integration (CI) fails on my grouped pull request
解决方案
如果失败是由单个依赖导致的，可使用 exclude-patterns 配置将该依赖排除出分组。Dependabot 将随后为该依赖单独创建拉取请求。
若想忽略该依赖的更新，需要执行以下任一操作。
- 在
dependabot.yml文件中为该依赖配置ignore规则。更多信息请参阅 Dependabot 选项参考。 - 在分组更新的拉取请求中，对该依赖使用
@dependabot ignore评论命令。更多信息请参阅 管理分组更新的拉取请求。
如果仍然出现 CI 失败，请移除分组配置，让 Dependabot 恢复为每个依赖单独创建拉取请求。随后检查并确认每个单独拉取请求的更新能够正常工作。
身份验证和注册表错误
无法解析或访问依赖项
错误信息： Dependabot can't resolve your LANGUAGE dependency files
API 错误类型： git_dependencies_not_reachable
如果 Dependabot 尝试检查仓库中的依赖引用是否需要更新，但无法访问一个或多个引用的文件，则此操作会失败。
私有包注册表错误
当 Dependabot 无法访问私有包注册表时，可能会产生以下错误。
| 错误信息 | API 错误类型 |
|---|---|
| "Dependabot can't reach a dependency in a private package registry" | private_source_not_reachable |
| "Dependabot can't authenticate to a private package registry" | private_source_authentication_failure |
| "Dependabot timed out while waiting for a private package registry" | private_source_timed_out |
| "Dependabot couldn't validate the certificate for a private package registry" | private_source_certificate_failure |
解决方案：确保所有引用的依赖均托管在可访问的位置。
仅限版本更新：在运行安全或版本更新时，某些生态系统必须能够从其源解析所有依赖，以验证更新是否成功。如果清单或锁定文件中包含任何私有依赖，Dependabot 必须能够访问这些依赖所在的位置。组织所有者可以在同一组织内授权 Dependabot 访问包含项目依赖的私有仓库。更多信息请参阅 管理组织的安全与分析设置。你可以在仓库的 dependabot.yml 配置文件中设置对私有注册表的访问，详情请见 配置 Dependabot 对私有注册表的访问。另外，Dependabot 并不对所有包管理器提供对私有 GitHub 依赖的支持。参见 Dependabot 支持的生态系统与仓库。
手动触发 Dependabot 拉取请求
如果你解除对 Dependabot 的阻止，可手动触发一次新的创建拉取请求的尝试。
安全更新：显示显示已修复错误的 Dependabot 警报，并点击 Create Dependabot security update（创建 Dependabot 安全更新）。
版本更新：在仓库的 Insights（洞察）选项卡下点击 Dependency graph（依赖图），随后点击 Dependabot 选项卡。点击 Last checked TIME ago（上次检查 时间 前）查看 Dependabot 在上一次版本更新检查期间生成的日志文件。然后点击 Check for updates（检查更新）。