{"meta":{"title":"状态检查","intro":"了解状态检查如何确保提交满足存储库条件、协助拉取请求评审以及管理生成、测试和部署等验证。","product":"拉取请求","breadcrumbs":[{"href":"/zh/pull-requests","title":"拉取请求"},{"href":"/zh/pull-requests/reference","title":"Reference"},{"href":"/zh/pull-requests/reference/status-checks","title":"状态检查"}],"documentType":"article"},"body":"# 状态检查\n\n了解状态检查如何确保提交满足存储库条件、协助拉取请求评审以及管理生成、测试和部署等验证。\n\n状态检查显示提交是否符合为存储库设置的条件。 它们通常由外部系统创建，例如持续集成生成、测试、代码扫描或部署检查。\n\n状态检查可帮助审阅者和维护人员了解拉取请求是否已准备好合并。 检查可以显示工作仍在运行、更改通过的验证或需要注意的内容。\n\n![提交和状态列表的屏幕截图。](/assets/images/help/pull_requests/commit-list-statuses.png)\n\n对仓库具有写入权限的任何人都可为仓库中的任何状态检查设置状态。\n\n如果受保护的分支需要状态检查，则必须通过这些检查才能合并拉取请求。 请参阅“[关于受保护分支](/zh/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)”。\n\n> \\[!NOTE]\n> 跳过的作业将报告其状态为“Success”。 即使是必需检查，也不会阻止拉取请求合并。\n\n## 状态检查的类型 GitHub\n\n有两种类型的状态检查 GitHub：\n\n| 类型                             | 详细程度         | 创建者      |\n| ------------------------------ | ------------ | -------- |\n| 检查                             | 详细的输出、批注和消息。 |          |\n| GitHub Apps，包括 GitHub Actions。 |              |          |\n| 提交状态                           | 提交状态更简单。     | 外部服务和集成。 |\n\n> \\[!NOTE]\n> GitHub Actions 在运行工作流时生成检查，而不是提交状态。\n\n具有对存储库推送访问权限的组织所有者和用户可以使用 's API 创建检查和提交状态 GitHub。 请参阅 [检验的 REST API 端点](/zh/rest/checks) 和 [提交状态的 REST API 端点](/zh/rest/commits/statuses)。\n\n## 检查\n\n检查可能包括生成日志、测试结果、批注和指向更多详细信息的链接。 在拉取请求中，“ **检查** ”选项卡可帮助你了解运行的验证以及检查通过或失败的原因。\n\n![拉取请求的“检查”选项卡的屏幕截图。 “检查”选项卡和用于选择提交的下拉菜单都以深橙色轮廓显示。](/assets/images/help/pull_requests/checks-summary-for-various-commits.png)\n\n> \\[!NOTE]\n> 仅当为存储库设置**检查**（而不是\\_提交状态\\_）时，才会为拉取请求填充“*检查*”选项卡。\n\n当检查点指向特定行时，详细信息还可以显示在拉取请求的 **“文件** ”选项卡中。 这有助于审阅者将自动反馈连接到正在更改的代码。\n\n## 跳过并请求对单个提交的检查\n\n某些存储库允许跳过或请求单个提交检查。 当检查与特定更改无关或未自动请求检查时，这非常有用。\n\n对于GitHub Actions工作流，可以通过在提交消息中包含跳过指令来跳过由事件`push`触发`pull_request`的工作流运行。 请参阅“[跳过工作流程运行](/zh/actions/how-tos/manage-workflow-runs/skip-workflow-runs)”。\n\n或者，要跳过或请求跳过所有提交检查，请在提交信息的末尾添加以下尾行之一：\n\n* 若要跳过检查进行提交，请输入提交消息以及简短、有意义的更改说明。 提交说明后，在右引号之前，添加两个空行，后接 `skip-checks: true`：\n\n  ```shell\n  $ git commit -m \"Update README\n  >\n  >\n  skip-checks: true\"\n  ```\n\n* 要\\_请求\\_提交检查，请键入提交消息和更改的简短有意义描述。 提交说明后，在右引号之前，添加两个空行，后接 `request-checks: true`：\n\n  ```shell\n  $ git commit -m \"Refactor usability tests\n  >\n  >\n  request-checks: true\"\n  ```\n\n默认情况下，Git 会自动删除连续换行符。 要使提交消息与输入的完全一样，请在提交时使用 `--cleanup=verbatim` 选项。 有关详细信息，请参阅 Git 文档中的 [`--cleanup=<mode>`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---cleanupltmodegt)。\n\n## 检查状态和结论\n\n检查在运行状态时移动，然后在完成时收到结论。 某些状态无法手动设置，并且保留为 GitHub Actions。\n\n\\| 地位 | Description |\nGitHub Actions 只？ |\n\\| --- | --- | --- |\n\\| `completed` | 检查流程已完成并得出了结论（请参阅下文）。 | No |\n\\| `expected` | 检查过程正在等待状态报告。 | 是的 |\n\\| `failure` | 检查运行失败了。 | No |\n\\| `in_progress` | 检查运行中。 | No |\n\\| `pending` | 检查运行位于队列前面，但已达到[基于组的并发](/zh/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency)限制。 | 是的 |\n\\| `queued` | 检查任务已在队列中。 | No |\n\\| `requested` | 已创建检查运行，但尚未在队列中。 | 是的 |\n\\| `startup_failure` | 检查套件在启动过程中失败。 此状态不适用于检查操作。 | 是的 |\n\\| `waiting` | 检查任务正在等待[部署保护规则](/zh/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)得到满足。 | 是的 |\n\n当检查的状态为`completed`时，它有一个结论。 成功的结论通常意味着检查不会阻止合并。 失败、超时或所需操作的结论通常意味着某人必须先查看详细信息，然后拉取请求才能合并。\n\n| 结论                                   | Description                                                                                                                                     |\n| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| `action_required`                    | 检查运行完成后提供了所需的操作。  有关详细信息，请参阅“[使用 REST API 与检查交互](/zh/rest/guides/using-the-rest-api-to-interact-with-checks#check-runs-and-requested-actions)”。 |\n| `cancelled`                          | 检查程序运行在完成之前已取消。                                                                                                                                 |\n| `failure`                            | 检查运行失败了。                                                                                                                                        |\n| `neutral`                            | 检查运行已完成，结果为中性。 这被视为依赖检查 GitHub Actions的成功。                                                                                                      |\n| `skipped`                            | \\*\\*                                                                                                                                            |\n| 已跳过例行检查。 这被视为依赖检查 GitHub Actions的成功。 |                                                                                                                                                 |\n| `stale`                              | 检查运行被标记为过时 GitHub ，因为它花费的时间太长。                                                                                                                  |\n| `success`                            | 检查过程已成功完成。                                                                                                                                      |\n| `timed_out`                          | 检查运行超时。                                                                                                                                         |\n\n## 校验的保留\n\nGitHub 将检查数据保留 400 天。 400 天后，数据将存档。 存档 10 天后，数据将永久删除。\n\n要将拉取请求与必需且已存档的检查合并，必须重新运行检查。"}