关于状态检查

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

对仓库具有写入权限的任何人都可为仓库中的任何状态检查设置状态。

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

如果存储库需要状态检查，则必须通过状态检查，然后才能将分支合并到受保护的分支中。 有关详细信息，请参阅“AUTOTITLE”。

GitHub 上的状态检查类型

GitHub 上的状态检查有两种类型：

• 检查
• 提交状态

“检查”与“提交状态”的不同之处在于它们提供行注释、更详细的消息，并且仅适用于 GitHub Apps。

具有仓库推送权限的用户和组织所有者，可以使用 GitHub 的 API 创建检查和提交状态。 有关详细信息，请参阅 AUTOTITLE 和 AUTOTITLE。

检查

拉取请求包含一个“Checks”选项卡，你可以在该选项卡中查看检查生成的详细构建输出，并重新运行失败的检查。

当提交中的特定行造成检查失败时，你会在拉取请求的“文件”选项卡中相关代码旁边看到有关失败、警告或通知的详细信息。

可以使用“检查”选项卡下的提交下拉菜单，浏览拉取请求中不同提交的检查摘要。

跳过和申请个别提交的检查

当仓库设置为自动申请检查推送时，您可以选择跳过所推送的个别提交的检查。 当存储库未设置为自动申请检查推送时，你可以请求检查你推送的个别提交。 有关这些设置的详细信息，请参阅“AUTOTITLE”。

还可以通过在提交消息中包含命令来跳过由 和 事件触发的工作流运行。 有关详细信息，请参阅“AUTOTITLE”

或者，要跳过或申请所有提交检查，请在提交消息末添加以下尾行之一：

• 若要跳过检查进行提交，请输入提交消息以及简短、有意义的更改说明。 提交说明后，在右引号之前，添加两个空行，后接 ：

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

• 若要请求对提交的检查，请输入提交消息以及简短、有意义的更改说明。 提交说明后，在右引号之前，添加两个空行，后接 ：

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

默认情况下，Git 会自动删除连续换行符。 要使提交消息与输入的完全一样，请在提交时使用 --cleanup=verbatim 选项。 有关详细信息，请参阅 Git 文档中的 --cleanup=<mode>。

检查状态和结论

检查可以有许多不同的状态。 状态描述了检查从创建到完成时的状态。 某些状态无法手动设置，并且为 GitHub Actions 保留。 当检查的状态为 时，就有了结论。 结论描述了检查的结果。 下面列出了所有可能的检查状态和结论。

状态	说明	仅 GitHub Actions？
completed	检查流程已完成并得出了结论（请参阅下文）。	否
expected	检查过程正在等待状态报告。	是
failure	检查运行失败了。	否
in_progress	检查运行正在进行中。	否
pending	检查运行位于队列的前面，但已达到基于组的并发限制。	是
queued	检查运行已排队。	否
requested	检查运行已创建，但尚未排队。	是
startup_failure	检查套件在启动过程中失败。 此状态不适用于检查操作。	是
waiting	检查运行正在等待满足部署保护规则。	是

结束语	说明
action_required	检查运行完成后提供了所需的操作。 有关详细信息，请参阅“AUTOTITLE”。
cancelled	检查运行在完成之前被取消。
failure	检查运行失败了。
neutral	检查运行已完成，结果为中性。 这被视为在 GitHub Actions 中的依赖检查的成功。
skipped	**
已跳过例行检查。 这被视为 GitHub Actions 中依赖检查的一次成功。
stale	检查运行被 GitHub 标记为过时，因为它花了太长时间。
success	检查过程已成功完成。
timed_out	检查运行超时。

检查的保留

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

要将拉取请求与必需且已存档的检查合并，必须重新运行检查。