排查 Dependabot 错误

关于 Dependabot 错误

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

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

使用 Dependabot security updates 调查错误

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

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

1. Dependabot security updates 未对仓库启用。
2. 警报针对未在锁文件中显式定义的间接或过渡依赖项。
3. 某个错误阻止了 Dependabot 创建拉取请求。

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

使用 Dependabot version updates

调查错误

当 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 recreate 或
• @dependabot rebase。

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

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

Dependabot 无法更新到所需的版本，因为已经为最新版本打开了拉取请求

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

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

不需要安全更新程序，因为 DEPENDENCY 不再易受攻击

仅限安全更新。 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.yml 文件中的 groups 配置设置可以应用于版本更新和安全更新。 使用 applies-to 密钥指定应用一组分组规则的位置（版本更新或安全更新）。

不能将单个分组规则集同时应用于_版本_更新和_安全_更新。 相反，如果要使用相同的条件对版本更新和安全更新进行分组，则必须定义两个分别单独命名的分组规则集。

配置分组的版本更新时，你必须为每个包生态系统配置组。 要调试问题，建议查看日志。 有关访问清单日志的信息，请参阅上面的“使用 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 将：

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

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

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

Dependabot 无法将一组依赖项分组到 Dependabot security updates 的单个拉取请求

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 可能存在问题。

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

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

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

仅限安全更新。 如果安全更新的分组拉取请求失败或者无法合并，建议你手动打开拉取请求，以升级中断性变更的版本。 手动更新分组拉取请求中包含的包时，Dependabot 将重定拉取请求的基准，使其不包含手动更新的包。

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

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

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

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

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

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

如果仍然看到 CI 失败，则应删除组配置，以便 Dependabot 还原为针对每个依赖项提出单个拉取请求。 然后，应检查并确认，对于每个单独的拉取请求，更新都能正常工作。

手动触发 Dependabot 拉取请求

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

• 安全更新 - 显示 Dependabot 警报，查看你修复的错误，然后单击“创建 Dependabot 安全更新” 。
• 版本更新 - 在存储库的“见解”选项卡上单击“依赖项关系图”，然后单击“Dependabot”选项卡 。单击“上次检查时间之前”，查看上次检查版本更新期间 Dependabot 生成的日志文件。 单击“检查更新”****。

延伸阅读

• “依赖关系图疑难排解”
• "漏洞依赖项检测疑难解答"