关于状态检查

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

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

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

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

GitHub 上的状态检查类型

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

• 检查

• 提交状态

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

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

检查

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

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

你可以使用“检查”**** 选项卡下的提交下拉菜单在拉取请求中各种提交的检查摘要之间导航。

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

当仓库设置为自动申请检查推送时，您可以选择跳过所推送的个别提交的检查。 当存储库_未_设置为自动请求推送检查时，你可以为推送的单个提交请求检查。 有关这些设置的详细信息，请参阅“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"
  

关于提交清理的说明

检查状态和结论

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

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

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

检查的保留

数据reusables.pull_requests.retention-checks-data %}