Status checks show whether commits meet the conditions set for a repository. They are usually created by external systems, such as continuous integration builds, tests, code scanning, or deployment checks.
Status checks help reviewers and maintainers understand whether a pull request is ready to merge. A check can show that work is still running, that changes passed validation, or that something needs attention.

Anyone with write permissions to a repository can set the state for any status check in the repository.
If status checks are required for a protected branch, they must pass before the pull request can be merged. See 关于受保护分支.
注意
跳过的作业将报告其状态为“Success”。 即使是必需检查,也不会阻止拉取请求合并。
Types of status checks on GitHub
There are two types of status checks on GitHub:
| Type | Detail level | Created by |
|---|---|---|
| Checks | Detailed output, annotations, and messages. | GitHub Apps, including GitHub Actions. |
| Commit statuses | A simpler status for a commit. | External services and integrations. |
注意
GitHub Actions generates checks, not commit statuses, when workflows are run.
Organization owners and users with push access to a repository can create checks and commit statuses with GitHub's API. See 检验的 REST API 端点 and 提交状态的 REST API 端点.
Checks
Checks can include build logs, test results, annotations, and links to more detail. In a pull request, the Checks tab helps you understand which validations ran and why a check passed or failed.

注意
The Checks tab is populated for pull requests only if you set up checks, not commit statuses, for the repository.
When a check points to a specific line, details can also appear in the Files tab of the pull request. This helps reviewers connect automated feedback to the code being changed.
Skipping and requesting checks for individual commits
Some repositories allow checks to be skipped or requested for individual commits. This can be useful when a check is not relevant to a specific change, or when checks are not requested automatically.
For GitHub Actions workflows, you can skip workflow runs triggered by the push and pull_request events by including a skip instruction in your commit message. See 跳过工作流程运行.
Alternatively, to skip or request all checks for your commit, add one of the following trailer lines to the end of your commit message:
-
To skip checks for a commit, type your commit message and a short, meaningful description of your changes. After your commit description, before the closing quotation, add two empty lines followed by
skip-checks: true:$ git commit -m "Update README > > skip-checks: true" -
To request checks for a commit, type your commit message and a short, meaningful description of your changes. After your commit description, before the closing quotation, add two empty lines followed by
request-checks: true:$ git commit -m "Refactor usability tests > > request-checks: true"
默认情况下,Git 会自动删除连续换行符。 要使提交消息与输入的完全一样,请在提交时使用 --cleanup=verbatim 选项。 有关详细信息,请参阅 Git 文档中的 --cleanup=<mode>。
Check statuses and conclusions
Checks move through statuses as they run, then receive a conclusion when they finish. Some statuses cannot be set manually and are reserved for GitHub Actions.
| Status | Description | GitHub Actions only? |
|---|---|---|
completed | The check run completed and has a conclusion (see below). | No |
expected | The check run is waiting for a status to be reported. | Yes |
failure | The check run failed. | No |
in_progress | The check run is in progress. | No |
pending | The check run is at the front of the queue but the group-based concurrency limit has been reached. | Yes |
queued | The check run has been queued. | No |
requested | The check run has been created but has not been queued. | Yes |
startup_failure | The check suite failed during startup. This status is not applicable to check runs. | Yes |
waiting | The check run is waiting for a deployment protection rule to be satisfied. | Yes |
When a check has a status of completed, it has a conclusion. A successful conclusion usually means the check does not block merging. A failure, timeout, or action-required conclusion usually means someone must review the details before the pull request can merge.
| Conclusion | Description |
|---|---|
action_required | The check run provided required actions upon its completion. For more information, see 使用 REST API 与检查交互. |
cancelled | The check run was cancelled before it completed. |
failure | The check run failed. |
neutral | The check run completed with a neutral result. This is treated as a success for dependent checks in GitHub Actions. |
skipped | The check run was skipped. This is treated as a success for dependent checks in GitHub Actions. |
stale | The check run was marked stale by GitHub because it took too long. |
success | The check run completed successfully. |
timed_out | The check run timed out. |
Retention of checks
GitHub 将检查数据保留 400 天。 400 天后,数据将存档。 存档 10 天后,数据将永久删除。
要将拉取请求与必需且已存档的检查合并,必须重新运行检查。