概述
与二进制通过/失败构建状态不同，GitHub Apps 可以报告丰富的状态，用详细信息注释代码行，并重新运行测试。管理检查的 REST API 仅供您的 GitHub Apps 使用。
有关如何将 REST API 与 GitHub App 一起使用的示例，请参阅“使用 GitHub App 构建 CI 检查”。
您可以将状态与 受保护的分支 一起使用，以防止人们过早地合并拉取请求。有关更多信息，请参阅“关于受保护的分支”。
关于检查套件
当有人将代码推送到存储库时，GitHub 会为最后一个提交创建一个检查套件。检查套件是单个 GitHub App 为特定提交创建的 检查运行 的集合。检查套件总结了套件中包含的检查运行的状态和结论。
status 可以是 queued、in_progress、requested、waiting、pending 或 completed。只有 GitHub Actions 可以将状态设置为 requested、waiting 或 pending。
如果状态为 completed，则结论可以是以下任何一种
action_requiredcancelledtimed_outfailureneutralskippedstalestartup_failuresuccess
检查套件报告检查套件 conclusion 中优先级最高的检查运行 conclusion。例如，如果三个检查运行的结论为 timed_out、success 和 neutral，则检查套件结论将为 timed_out。
默认情况下，GitHub 会在代码推送到仓库时自动创建检查套件。此默认流程会将 `check_suite` 事件（带有 `requested` 操作）发送到所有具有 `checks:write` 权限的 GitHub 应用。当您的 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_outfailureneutralskippedsuccess
如果检查运行处于不完整状态超过 14 天，则检查运行的 `conclusion` 将变为 `stale`，并在 GitHub 上显示为过时，并带有 . 只有 GitHub 可以将检查运行标记为 `stale`。有关检查运行可能结论的更多信息，请参阅 `conclusion` 参数。
收到 check_suite webhook 后，您可以立即创建检查运行，即使检查尚未完成。您可以使用 queued、in_progress 或 completed 值更新检查运行的 status，并在更多详细信息可用时更新 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 应用执行其他任务。
例如，代码 linting 应用可以使用请求的操作在拉取请求中显示一个按钮，以自动修复检测到的语法错误。
要创建一个可以请求您的应用执行其他操作的按钮，请在 actions 对象 中使用 创建检查运行。例如，下面的 actions 对象在拉取请求的“检查”选项卡中显示一个带有“修复此问题”标签的按钮。该按钮在检查运行完成后出现。
"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 事件时，它可以在 webhook 负载中查找 requested_action.identifier 键以确定单击了哪个按钮并执行请求的任务。
有关如何使用 REST API 设置请求操作的详细示例，请参阅“使用 GitHub App 构建 CI 检查”。
检查数据保留
GitHub.com 会保留 400 天的检查数据。400 天后，数据将被归档。归档 10 天后，数据将被永久删除。
要合并包含已要求且已归档的检查的拉取请求，您必须重新运行检查。