排查 Dependabot 错误

关于 Dependabot 错误

Dependabot 提出拉取请求，以更新依赖项。 Dependabot 可能会针对版本更新和/或安全更新提出拉取请求，具体取决于存储库的配置方式。您可以按与任何其他拉取请求相同的方式管理这些拉取请求，但也有一些额外的可用命令。有关启用 Dependabot 的信息，请参阅“配置 Dependabot 安全更新”和“配置 Dependabot 版本更新”。

如果有任何因素阻止 Dependabot 提出拉取请求，则报告为错误。

注意：Dependabot 不会为非活动存储库创建拉取请求。有关非活动条件的信息，请分别参阅“关于 Dependabot 安全更新”和“关于 Dependabot 版本更新”以获取安全性和版本更新。

使用 Dependabot security updates 调查错误

当 Dependabot 被阻止创建拉取请求以修复 Dependabot 警报时，它会在警报上发布错误消息。 Dependabot alerts 视图显示尚未解决的所有警报列表。若要访问警报视图，请单击存储库“安全”选项卡上的“Dependabot alerts” 。如果旨在修复有漏洞依赖项的拉取请求已生成，则警报将包括指向该拉取请求的链接。

Dependabot alerts 视图的屏幕截图，其中显示了两个警报。在一个警报的右侧，标题为“#353”的拉取请求链接以橙色边框突出显示。

有多个原因可能导致警报中没有拉取请求链接：

Dependabot security updates 未对仓库启用。
警报适用于恶意软件，并且包没有安全版本。
警报针对未在锁文件中显式定义的间接或过渡依赖项。
某个错误阻止了 Dependabot 创建拉取请求。

如果某个错误阻止了 Dependabot 创建拉取请求，您可以通过单击警报来显示错误详情。

使用 Dependabot version updates

调查错误

当 Dependabot 被阻止创建拉取请求以更新生态系统中的依赖项时，你可以查看作业日志列表，了解有关错误上发布错误图标。

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

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

清单文件的 Dependabot 作业日志项目的屏幕截图。名为“查看日志”的按钮以深橙色边框突出显示。

有关详细信息，请参阅“查看 Dependabot 作业日志”。

了解 Dependabot 错误

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

Dependabot 无法将依赖项更新到无漏洞版本

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

每个具有依赖项的应用程序都有一个依赖关系图，即应用程序直接或间接依赖的每个包版本的定向非循环图。每次更新依赖项时，必须解决此图，否则将无法构建应用程序。当生态系统具有深刻而复杂的依赖关系图（例如 npm 和 RubyGems）时，如果不升级整个生态系统，往往难以升级单个依赖项。

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

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

仅限安全更新。 Dependabot 更新显式定义的可传递依赖项，这些依赖项对于所有生态系统而言易受攻击。对于 npm，Dependabot 会引发拉取请求，如果这是修复可传递依赖项的唯一方法，则该请求还会更新父依赖项。

例如，在 A 版本 ~2.0.0 上有一个依赖项的项目在 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 无法更新到所需的版本，因为已经为最新版本打开了拉取请求

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

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

Dependabot 在更新过程中超时

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

此错误难以解决。如果版本更新超时，可以使用 allow 参数来指定更新最重要的依赖项，或者使用 ignore 参数从更新中排除某些依赖项。更新配置可能使 Dependabot 能够在规定时间内检查版本更新并生成请求。

如果安全更新超时，您可以通过保持依赖项更新（例如，启用版本更新）来减少更新需要。有关详细信息，请参阅“配置 Dependabot 版本更新”。

Dependabot 无法再打开拉取请求

Dependabot 生成的打开拉取请求数量存在限制。如果达到此限制，将无法打开新的拉取请求，并报告此错误。解决此错误的最佳方法是审查并合并一些打开的拉取请求。

安全性和版本更新拉取请求有各自的限制，因此打开版本更新拉取请求不会阻止安全更新拉取请求的创建。安全更新拉取请求的限制是 10。默认情况下，版本更新的限制为 5，但你可以使用配置文件中的 open-pull-requests-limit 参数来更改它。有关详细信息，请参阅“dependabot.yml 文件的配置选项”。

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

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

如果 Dependabot 尝试检查是否需要更新仓库中的依赖项引用，但无法访问一个或多个依赖项文件，则操作将失败，并返回错误消息“Dependabot can't resolve your LANGUAGE dependency files（无法解析语言依赖项文件）”。 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 version updates 创建组。 Dependabot security updates 不支持分组更新。此外，如果存在针对某个易受攻击包的分组拉取请求，则 Dependabot security updates 将始终尝试创建单独的拉取请求，即使现有组拉取请求针对相同或更高版本的更新。

必须为每个包生态系统配置组。要调试问题，建议查看日志。有关访问清单日志的信息，请参阅上面的“使用 Dependabot version updates 调查错误”。

你可能无意中创建了空组。例如，在为整体工作在 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 将：

查看依赖项列表，并将工作限制为仅在 production 中使用的依赖项。
尝试创建名为 development-dependencies 的组，即此缩减列表的子集。
由于步骤 1 中删除了所有 development 依赖项，因此 development-dependencies 组为空。
**** 单独更新不在组中的所有依赖项。由于生产中的依赖项组为空，Dependabot 将忽略该组，并为每个依赖项创建单独的拉取请求。

需要确保配置设置不会彼此取消，并在配置文件中相应地进行更新。

有关如何为 Dependabot version updates 配置组的详细信息，请参阅“dependabot.yml 文件的配置选项”。

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

**仅版本更新。**Dependabot 将在日志中以及日志末尾的作业摘要中显示失败的更新。应在拉取请求中使用 @dependabot recreate 注释再次生成组。有关详细信息，请参阅“管理依赖项更新的所有拉取请求”。

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

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

如果要忽略依赖关系的版本更新，必须执行下列操作之一。

为 ignore 文件中的依赖关系配置 dependabot.yml 规则。有关详细信息，请参阅“dependabot.yml 文件的配置选项”。
对分组更新的拉取请求中的依赖关系使用 @dependabot ignore 注释命令。有关详细信息，请参阅“管理依赖项更新的所有拉取请求”。

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

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