跳至主要内容

Dependabot 错误故障排除

有时 Dependabot 无法发出拉取请求来更新您的依赖项。您可以查看错误并解除 Dependabot 的阻止。

关于 Dependabot 错误

Dependabot 发出拉取请求以更新依赖项。根据您仓库的配置方式,Dependabot 可能会为版本更新和/或安全更新发出拉取请求。您可以像管理任何其他拉取请求一样管理这些拉取请求,但还有一些额外的命令可用。有关启用 Dependabot 依赖项更新的信息,请参阅“配置 Dependabot 安全更新”和“配置 Dependabot 版本更新”。

如果任何事情阻止 Dependabot 发出拉取请求,则会将其报告为错误。

注意

Dependabot 不会为不活跃的仓库创建拉取请求。有关不活动标准的信息,请分别参阅“关于 Dependabot 安全更新”和“关于 Dependabot 版本更新”,以获取安全和版本更新的信息。

有关在 GitHub Actions 运行器上运行 Dependabot 时进行故障排除的更多信息,请参阅“关于 GitHub Actions 运行器上的 Dependabot”。

调查 Dependabot 安全更新错误

当 Dependabot 无法创建拉取请求来修复 Dependabot 警报时,它会在警报上发布错误消息。Dependabot 警报视图显示尚未解决的任何警报的列表。要访问警报视图,请在存储库的“**安全**”选项卡上单击“**Dependabot 警报**”。如果已生成修复漏洞依赖项的拉取请求,则警报中包含指向该拉取请求的链接。

Screenshot of the Dependabot alerts view, showing two alerts. To the right side of one alert, a link to a pull request, titled "#353", is highlighted with an orange outline.

警报可能没有拉取请求链接有几个原因

  1. 存储库未启用 Dependabot 安全更新。
  2. 警报针对的是锁定文件中未明确定义的间接或传递依赖项。
  3. 错误阻止了 Dependabot 创建拉取请求。

如果错误阻止了 Dependabot 创建拉取请求,您可以通过单击警报来显示错误的详细信息。

调查 Dependabot 版本更新错误

当 Dependabot 无法创建拉取请求来更新某个生态系统中的依赖项时,您可以查看作业日志列表以了解有关错误的更多信息。

作业日志列表可从存储库的依赖关系图中访问。在依赖关系图中,单击“**Dependabot**”选项卡,然后在受影响的清单文件右侧单击“**最近的更新作业**”。

要查看特定作业的完整日志文件,请在您感兴趣的日志条目右侧单击“**查看日志**”。

Screenshot of the Dependabot job log entries for a manifest file. A button, called "View logs", is highlighted in a dark orange outline.

有关更多信息,请参阅“查看 Dependabot 作业日志”。

了解 Dependabot 错误

安全更新的拉取请求用于将漏洞依赖项升级到包含漏洞修复的最低版本。相比之下,版本更新的拉取请求用于将依赖项升级到包清单和 Dependabot 配置文件允许的最新版本。因此,某些错误特定于一种更新类型。

Dependabot 无法将 DEPENDENCY 更新到非漏洞版本

**仅限安全更新。**Dependabot 无法创建拉取请求以将漏洞依赖项更新到安全版本,而不会破坏此存储库的依赖关系图中的其他依赖项。

每个具有依赖项的应用程序都有一个依赖关系图,即应用程序直接或间接依赖的每个包版本的定向无环图。每次更新依赖项时,此图都必须解析,否则应用程序将无法构建。当某个生态系统具有深度且复杂的依赖关系图时(例如,npm 和 RubyGems),通常不可能升级单个依赖项而不升级整个生态系统。

避免此问题的最佳方法是及时了解最新发布的版本,例如,通过启用版本更新。这增加了可以通过简单的升级解决一个依赖项中的漏洞的可能性,而不会破坏依赖关系图。有关更多信息,请参阅“配置 Dependabot 版本更新”。

Dependabot 尝试在没有警报的情况下更新依赖项

**仅限安全更新。**Dependabot 会更新所有生态系统中易受攻击的显式定义的传递依赖项。对于 npm,如果这是修复传递依赖项的唯一方法,Dependabot 将提出一个也更新父依赖项的拉取请求。

例如,一个项目依赖于版本为 ~2.0.0A,该项目具有对版本为 ~1.0.0B 的传递依赖项,该依赖项已解析为 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 将查找对依赖项 A 的更新,以允许使用 B 的已修复版本。

Dependabot 自动生成一个拉取请求,该请求升级锁定的父级和子级传递依赖项。

Dependabot 无法关闭已在默认分支上应用的更新的打开的拉取请求

Dependabot 将关闭依赖项更新的拉取请求,一旦检测到这些更新已提交到默认分支。但是,在极少数情况下,拉取请求可能会保持打开状态。如果您注意到您已手动提交了对依赖项的更新,并且该更新的拉取请求仍处于打开状态,则可以在拉取请求上的注释中使用以下命令之一

  • @dependabot recreate,或
  • @dependabot rebase.

这两个注释都将触发 Dependabot 检查依赖项是否不再可升级或存在漏洞。如果 Dependabot 检测到不再需要拉取请求,它将在此特定情况下关闭拉取请求。

有关 Dependabot 注释命令的更多信息,请参阅“管理依赖项更新的拉取请求”。

Dependabot 无法更新到所需版本,因为已存在针对最新版本的打开的拉取请求

**仅限安全更新。**Dependabot 不会创建拉取请求以将漏洞依赖项更新到安全版本,因为已存在更新此依赖项的打开的拉取请求。当在一个依赖项中检测到漏洞并且已存在更新该依赖项到最新版本的打开的拉取请求时,您将看到此错误。

有两个选项:您可以查看打开的拉取请求并在确信更改安全后立即合并它,或者关闭该拉取请求并触发新的安全更新拉取请求。有关更多信息,请参阅“手动触发 Dependabot 拉取请求”。

不需要安全更新,因为 DEPENDENCY 不再存在漏洞

**仅限安全更新。**Dependabot 无法关闭更新不属于或不再属于漏洞的依赖项的拉取请求。当依赖关系图数据陈旧或依赖关系图和 Dependabot 在依赖项的特定版本是否易受攻击方面存在分歧时,您可能会看到此错误。

为了调试问题,我们建议您首先检查存储库的依赖关系图,查看它为依赖项检测到的版本,并检查标识的版本是否与存储库中使用的版本匹配。

如果您怀疑依赖关系图数据已过期,则可能需要手动更新存储库的依赖关系图或进一步调查您的依赖项信息。有关更多信息,请参阅“解决依赖关系图问题”。

如果您能够确认依赖项版本不再存在漏洞,则可以关闭 Dependabot 拉取请求。

Dependabot 在更新期间超时

Dependabot 花费的时间超过了评估所需更新和准备拉取请求的最大允许时间。此错误通常仅在具有许多清单文件的较大型存储库中看到,例如,具有数百个 package.json 文件的 npm 或 yarn monorepo 项目。Composer 生态系统的更新也需要更长的时间来评估,并且可能会超时。

此错误很难解决。如果版本更新超时,您可以使用 allow 参数指定最重要的要更新的依赖项,或者使用 ignore 参数将某些依赖项排除在更新之外。更新您的配置可能会允许 Dependabot 在可用时间内查看版本更新并生成拉取请求。

如果安全更新超时,您可以通过保持依赖项更新来减少这种情况发生的可能性,例如,通过启用版本更新。有关更多信息,请参阅“配置 Dependabot 版本更新”。

Dependabot 无法再打开任何拉取请求

Dependabot 生成的打开的拉取请求数量有限制。达到此限制后,将不再打开新的拉取请求,并报告此错误。解决此错误的最佳方法是查看并合并一些打开的拉取请求。

安全更新和版本更新拉取请求有单独的限制,以便打开的版本更新拉取请求不会阻止创建安全更新拉取请求。安全更新拉取请求的限制为 10。默认情况下,版本更新的限制为 5,但您可以使用配置文件中的 open-pull-requests-limit 参数更改此限制。有关更多信息,请参阅“Dependabot.yml 文件的配置选项”。

解决此错误的最佳方法是合并或关闭一些现有的拉取请求,并手动触发新的拉取请求。有关更多信息,请参阅“手动触发 Dependabot 拉取请求”。

Dependabot 无法解析或访问您的依赖项

如果 Dependabot 尝试检查存储库中的依赖项引用是否需要更新,但无法访问一个或多个引用的文件,则操作将失败并显示错误消息“Dependabot 无法解析您的 LANGUAGE 依赖项文件”。API 错误类型为 git_dependencies_not_reachable

类似地,如果 Dependabot 无法访问依赖项所在的私有包注册表,则会生成以下错误之一

  • “Dependabot 无法访问私有包注册表中的依赖项”
    (API 错误类型:private_source_not_reachable
  • “Dependabot 无法对私有包注册表进行身份验证”
    (API 错误类型:private_source_authentication_failure
  • “Dependabot 在等待私有包注册表时超时”
    (API 错误类型:private_source_timed_out
  • “Dependabot 无法验证私有包注册表的证书”
    (API 错误类型:private_source_certificate_failure

要允许 Dependabot 成功更新依赖项引用,请确保所有引用的依赖项都托管在可访问的位置。

仅限版本更新。 在运行安全或版本更新时,某些生态系统必须能够从其源解析所有依赖项,以验证更新是否成功。如果您的清单或锁定文件包含任何私有依赖项,则 Dependabot 必须能够访问托管这些依赖项的位置。组织所有者可以授予 Dependabot 访问同一组织内项目依赖项所在的私有存储库的权限。有关更多信息,请参阅“管理组织的安全和分析设置”。您可以在存储库的dependabot.yml配置文件中配置对私有注册表的访问。有关更多信息,请参阅“dependabot.yml 文件的配置选项”。此外,Dependabot 并不支持所有包管理器的私有 GitHub 依赖项。有关更多信息,请参阅“Dependabot 支持的生态系统和存储库”。

Dependabot 无法将一组依赖项分组到 Dependabot 版本更新的单个拉取请求中

dependabot.yml 文件中的groups配置设置可以应用于版本更新和安全更新。使用applies-to键指定应用一组分组规则的位置(版本更新或安全更新)。

您不能将一组分组规则同时应用于版本更新和安全更新。相反,如果您希望使用相同的标准对版本更新和安全更新进行分组,则必须定义两个分别命名的分组规则集。

配置分组版本更新时,必须为每个包生态系统配置组。要调试问题,我们建议您查看日志。有关访问清单日志的信息,请参阅上面“调查 Dependabot 版本更新错误”。

您可能无意中创建了空组。例如,当您为整体作业的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

在此示例中,Dependabot 将

  1. 查看您的依赖项列表,并将作业限制为仅在production中使用的依赖项。
  2. 尝试创建一个名为development-dependencies的组,它是此缩减列表的子集。
  3. 发现development-dependencies组为空,因为所有development依赖项都在步骤 1 中被删除了。
  4. 单独更新不在该组中的所有依赖项。由于生产环境中依赖项的组为空,Dependabot 将忽略该组,并为每个依赖项创建一个单独的拉取请求。

您需要确保配置设置不会相互抵消,并在您的配置文件中适当地更新它们。

有关如何为 Dependabot 版本更新配置组的更多信息,请参阅“dependabot.yml 文件的配置选项”。

Dependabot 无法将一组依赖项分组到 Dependabot 安全更新的单个拉取请求中

dependabot.yml 文件中的groups配置设置可以应用于版本更新和安全更新。使用applies-to键指定应用一组分组规则的位置(版本更新或安全更新)。检查您是否已配置分组以应用于安全更新。如果applies-to键不存在于配置中的一组分组规则中,则默认情况下,任何组规则都只应用于版本更新。

您不能将一组分组规则同时应用于版本更新和安全更新。相反,如果您希望使用相同的标准对版本更新和安全更新进行分组,则必须定义两个分别命名的分组规则集。

对于分组的安全更新,Dependabot 使用以下指南创建分组的拉取请求。

  • 当为使用directories键的配置指定分组规则时,Dependabot **将**对来自同一包生态系统但位于不同目录中的依赖项进行分组。
  • Dependabot **将**将dependabot.yml文件中其他相关的自定义选项应用于分组安全更新的拉取请求。在dependabot.yml文件中配置的组规则将覆盖在组织或存储库级别启用或禁用分组安全更新的用户界面设置。
  • Dependabot **不会**将来自不同包生态系统的依赖项组合在一起。
  • Dependabot **不会**将安全更新与版本更新组合在一起。

有关更多信息,请参阅“自定义依赖项更新”和“关于 Dependabot 安全更新”。

Dependabot 无法更新分组拉取请求中的一个依赖项

您可以使用不同的故障排除技术来处理版本更新失败和安全更新失败。

处理分组版本更新中的失败

仅限版本更新。 Dependabot 将在您的日志中以及日志末尾的作业摘要中显示失败的更新。您应该在拉取请求中使用@dependabot recreate注释重新构建组。有关更多信息,请参阅“管理依赖项更新的拉取请求”。

如果依赖项仍然无法更新,则应使用exclude-patterns配置将依赖项从组中排除。然后,Dependabot 将发出单独的拉取请求来更新依赖项。

如果依赖项仍然无法更新,则可能是依赖项本身或该特定生态系统的 Dependabot 存在问题。

如果要忽略依赖项的更新,则必须执行以下操作之一。

处理分组安全更新中的失败

仅限安全更新。 如果安全更新的分组拉取请求失败或无法合并,我们建议您手动打开拉取请求以更新重大更改的版本。当您手动更新分组拉取请求中包含的包时,Dependabot 将重新设置拉取请求的基础,以便它不包含手动更新的包。

如果要忽略依赖项的更新,则必须执行以下操作之一。

我的分组拉取请求上的持续集成 (CI) 失败

仅限版本更新。 如果失败是由于单个依赖项导致的,则应使用exclude-patterns配置将依赖项从组中排除。然后,Dependabot 将发出单独的拉取请求来更新依赖项。

如果要忽略依赖项的更新,则必须执行以下操作之一。

如果继续出现 CI 失败,则应删除组配置,以便 Dependabot 恢复为为每个依赖项发出单独的拉取请求。然后,您应该检查并确认更新是否对每个单独的拉取请求都能正常工作。

手动触发 Dependabot 拉取请求

如果取消阻止 Dependabot,您可以手动触发创建拉取请求的新尝试。

  • 安全更新 - 显示显示您已修复错误的 Dependabot 警报,然后单击创建 Dependabot 安全更新
  • 版本更新 - 在存储库的Insights选项卡上,单击依赖项图,然后单击Dependabot选项卡。单击上次检查于 TIME以查看 Dependabot 在上次检查版本更新时生成的日志文件。单击检查更新

进一步阅读