关于状态检查

状态检查基于外部流程，例如持续集成构建，这些构建会在您对仓库的每次推送时运行。您可以在拉取请求中查看每个提交旁边的状态检查的‘待处理’、‘通过’或‘失败’状态。

拥有仓库写权限的任何人都可以设置该仓库中任意状态检查的状态。

您可以在仓库的分支页面或拉取请求列表中看到分支上最近一次提交的整体状态。

如果仓库要求状态检查，则必须在将分支合并到受保护分支之前通过这些检查。欲了解更多信息，请参阅受保护分支概述。

GitHub 上的状态检查类型

GitHub 上有两种状态检查类型

• 检查
• 提交状态

检查不同于提交状态，因为它们提供行注释、更详细的消息，并且仅可用于 GitHub 应用程序。

组织所有者和拥有仓库推送权限的用户可以使用 GitHub 的 API 创建检查和提交状态。欲了解更多信息，请参阅检查的 REST API 端点和提交状态的 REST API 端点。

检查

拉取请求有一个 检查 选项卡，您可以在其中查看检查的详细构建输出并重新运行失败的检查。

当提交中的特定行导致检查失败时，您将在拉取请求的 文件 选项卡中相应代码旁看到有关失败、警告或提示的详细信息。

您可以使用 检查 选项卡下的提交下拉菜单，在拉取请求中不同提交的检查摘要之间进行切换。

为单个提交跳过和请求检查

当仓库设置为自动为推送请求检查时，您可以选择为您推送的单个提交跳过检查。当仓库未设置为自动为推送请求检查时，您可以为您推送的单个提交请求检查。如需了解这些设置的更多信息，请参阅检查套件的 REST API 端点。

您还可以在提交信息中包含指令，以跳过由 push 和 pull_request 事件触发的工作流运行。详细信息请参阅跳过工作流运行

或者，要为您的提交跳过或请求所有检查，请在提交信息末尾添加以下任意一行尾部信息

• 要为提交跳过检查，在编写提交信息及对更改的简短、明确描述后，在结尾引号前添加两个空行，然后写入 skip-checks: true

  $ git commit -m "Update README
  >
  >
  skip-checks: true"
  

• 要为提交请求检查，在提交信息及对更改的简短、明确描述后，在结尾引号前添加两个空行，然后写入 request-checks: true

  $ git commit -m "Refactor usability tests
  >
  >
  request-checks: true"
  

默认情况下，Git 会自动删除连续的换行。若要保持提交信息完全如您所写，请在提交时使用 --cleanup=verbatim 选项。更多信息请参阅 Git 文档中的--cleanup=<mode>。

检查状态和结论

检查可以有多种不同的状态。状态描述了检查从创建到完成的整个过程。某些状态无法手动设置，仅供 GitHub Actions 使用。当检查的状态为 completed 时，会有一个结论。结论描述了检查的结果。所有可能的检查状态和结论列举如下。

状态	描述	仅 GitHub Actions？
已完成	检查运行已完成并有一个结论（见下文）。	否
预期	检查运行正等待报告状态。	是
失败	检查运行失败。	否
进行中	检查运行正在进行中。	否
待处理	检查运行位于队列前端，但已达基于组的并发限制。	是
已排队	检查运行已排入队列。	否
已请求	检查运行已创建但尚未排队。	是
启动失败	检查套件在启动期间失败。此状态不适用于检查运行。	是
等待中	检查运行正在等待满足部署保护规则。	是

结论	描述
需要操作	检查运行在完成后提供了所需的操作。更多信息请参阅使用 REST API 与检查交互。
已取消	检查运行在完成前被取消。
失败	检查运行失败。
中立	检查运行以中立结果完成。这在 GitHub Actions 中被视为成功，对依赖检查有效。
已跳过	检查运行被跳过。这在 GitHub Actions 中被视为成功，对依赖检查有效。
已过期	检查运行因耗时过长而被 GitHub 标记为过期。
成功	检查运行成功完成。
超时	检查运行已超时。

检查的保留

GitHub 会保留检查数据 400 天。400 天后，数据会被归档。归档后 10 天，数据将被永久删除。

要合并包含必需且已归档检查的拉取请求，必须重新运行这些检查。