概览
与其使用二元的通过/失败构建状态，GitHub 应用可以报告丰富的状态、在代码行上添加详细信息标注，并重新运行测试。用于管理检查的 REST API 仅对您的 GitHub 应用开放。
有关如何在 GitHub 应用中使用 REST API 的示例，请参阅使用 GitHub 应用构建 CI 检查。
您可以将状态与受保护分支一起使用，以防止人们过早合并拉取请求。有关更多信息，请参阅关于受保护分支。
关于检查套件
当有人向仓库推送代码时，GitHub 会为最近一次提交创建一个检查套件。检查套件是由单个 GitHub 应用针对特定提交创建的检查运行的集合。检查套件汇总了其包含的检查运行的状态和结论。
status 可以是 queued、in_progress、requested、waiting、pending 或 completed。仅 GitHub Actions 能将状态设置为 requested、waiting 或 pending。
如果状态为 completed，则结论可以是以下任意一种
action_requiredcancelledtimed_out失败neutralskippedstalestartup_failure成功
检查套件在其 conclusion 中报告最高优先级的检查运行 conclusion。例如，如果三个检查运行的结论分别为 timed_out、success 和 neutral，则检查套件的结论将为 timed_out。
默认情况下，GitHub 在代码推送到仓库时会自动创建检查套件。此默认流程会向所有拥有 checks:write 权限的 GitHub 应用发送 check_suite 事件（action 为 requested）。当您的 GitHub 应用收到 check_suite 事件后，它可以为最新的提交创建新的检查运行。GitHub 会根据检查运行所属的仓库和 SHA 自动将新检查运行添加到相应的检查套件中。
如果您不想使用默认的自动流程，可以自行控制检查套件的创建时机。要更改检查套件创建的默认设置，请使用更新仓库检查套件偏好设置端点。对自动流程设置的所有更改都会记录在仓库的审计日志中。如果已禁用自动流程，您可以使用创建检查套件端点手动创建检查套件。随后仍应使用创建检查运行端点为提交提供反馈。
对 REST API 与检查交互的写入权限仅对 GitHub 应用开放。OAuth 应用和已认证用户可以查看检查运行和检查套件，但无法创建它们。如果您并未构建 GitHub 应用，可能更感兴趣的是使用 REST API 与提交状态交互。
要使用管理检查套件的端点，GitHub 应用必须具备 checks:write 权限，并且可以订阅check_suite Webhook。
有关如何以 GitHub 应用身份进行身份验证的说明，请参阅关于使用 GitHub 应用进行身份验证。
关于检查运行
检查运行是检查套件中的单个测试。每个运行都包含状态和结论。
status 可以是 queued、in_progress、requested、waiting、pending 或 completed。仅 GitHub Actions 能将状态设置为 requested、waiting 或 pending。
如果状态为 completed，则结论可以是以下任意一种
action_requiredcancelledtimed_out失败neutralskipped成功
如果检查运行在超过 14 天的时间里保持未完成状态，则该检查运行的 conclusion 将变为 stale，并在 GitHub 上显示为已过期。只有 GitHub 本身可以将检查运行标记为 stale。有关检查运行可能的结论信息，请参阅conclusion 参数。
只要收到check_suite Webhook，您即可以创建检查运行，即使检查尚未完成。您可以在检查运行完成过程中更新其 status（取值 queued、in_progress 或 completed），并在获得更多细节时更新 output。检查运行可以包含时间戳、指向您外部站点的详细链接、针对特定代码行的详细标注以及所执行分析的信息。
标注会将检查运行的信息添加到特定代码行。每个标注包含一个 annotation_level 属性，可为 notice、warning 或 failure。标注还包含 path、start_line 与 end_line，用于指明标注所在的位置，并包含 message 用于描述结果。更多信息，请参阅检查运行的 REST API 端点。
检查也可以在 GitHub UI 中手动重新运行。有关详细信息，请参阅关于状态检查。当此操作发生时，创建该检查运行的 GitHub 应用将收到check_run Webhook，要求创建新的检查运行。如果您在未创建检查套件的情况下创建了检查运行，GitHub 会自动为您创建相应的检查套件。
对 REST API 与检查交互的写入权限仅对 GitHub 应用开放。OAuth 应用和已认证用户可以查看检查运行和检查套件，但无法创建它们。如果您并未构建 GitHub 应用，可能更感兴趣的是使用 REST API 与提交状态交互。
要使用管理检查运行的端点，GitHub 应用必须具备 checks:write 权限，并且可以订阅check_run Webhook。
检查运行和请求的操作
当您为检查运行配置请求的操作（注意不要与 GitHub Actions 混淆）时，您可以在 GitHub 上的拉取请求视图中显示一个按钮，供用户请求您的 GitHub 应用执行额外任务。
例如，代码 lint 应用可以使用请求的操作在拉取请求中显示一个按钮，以自动修复检测到的语法错误。
要创建一个能够请求您应用执行额外操作的按钮，请在创建检查运行时使用actions 对象。例如，下列 actions 对象会在拉取请求的Checks标签页中显示一个标记为“Fix this.”的按钮，该按钮会在检查运行完成后出现。
"actions": [{
"label": "Fix this",
"description": "Let us fix that for you",
"identifier": "fix_errors"
}]
当用户点击该按钮时，GitHub 会向您的应用发送check_run.requested_action Webhook。当您的应用收到 check_run.requested_action 事件后，可在 Webhook 负载中查找 requested_action.identifier 键，以确定用户点击了哪个按钮并执行相应的任务。
有关如何使用 REST API 设置请求操作的详细示例，请参阅使用 GitHub 应用构建 CI 检查。
检查数据的保留
GitHub 会保留检查数据 400 天。400 天后，数据会被归档。归档后 10 天，数据将被永久删除。
要合并既为必需又已归档的检查的拉取请求，必须重新运行这些检查。