Skip to main content

关于状态检查

状态检查用于获知您的提交是否符合为您参与的仓库设置的条件。

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

提交和状态列表的屏幕截图。

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

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

如果需要对仓库进行状态检查,必须通过所需的状态检查后,您才可将分支合并到受保护分支。 有关详细信息,请参阅“关于受保护分支”。

Note

跳过的作业将报告其状态为“Success”。 即使是必需检查,也不会阻止拉取请求合并。

GitHub 上的状态检查类型

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

  • 检查
  • 提交状态

检查”与“提交状态”的不同之处在于它们提供行注释、更详细的消息,并且仅适用于 GitHub Apps。

Note

当工作流正在运行时,GitHub Actions 生成检查而不是提交状态。

组织所有者和能够推送到仓库的用户可使用 GitHub 的 API 创建检查和提交状态。 有关详细信息,请参阅 检查的 REST API 终结点适用于提交状态的 REST API 终结点

检查

在存储库中设置“检查”时,拉取请求会有一个“检查”选项卡,可以在其中查看检查的详细构建输出并重新运行失败的检查。

Note

仅当你为存储库设置了“检查”(而不是“提交状态”)时,才会为拉取请求填充“检查”选项卡****____。

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

可以使用“检查”选项卡下的提交下拉菜单,浏览拉取请求中不同提交的检查摘要。

拉取请求的“检查”选项卡的屏幕截图。 “检查”选项卡和用于选择提交的下拉菜单都以深橙色轮廓显示。

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

当仓库设置为自动申请检查推送时,您可以选择跳过所推送的个别提交的检查。 当存储库未设置为自动申请检查推送时,你可以请求检查你推送的个别提交。 有关这些设置的详细信息,请参阅“检查套件的 REST API 终结点”。

还可以通过在提交消息中包含命令来跳过由 pushpull_request 事件触发的工作流运行。 有关详细信息,请参阅“跳过工作流程运行

或者,要跳过或申请所有提交检查,请在提交消息末添加以下尾行之一:

  • 若要跳过检查进行提交,请输入提交消息以及简短、有意义的更改说明。 提交说明后,在右引号之前,添加两个空行,后接 skip-checks: true

    $ git commit -m "Update README
    >
    >
    skip-checks: true"
    
  • 若要请求检查进行提交,请输入提交消息以及简短、有意义的更改说明。 提交说明后,在右引号之前,添加两个空行,后接 request-checks: true

    $ git commit -m "Refactor usability tests
    >
    >
    request-checks: true"
    

默认情况下,Git 会自动删除连续换行符。 要使提交消息与输入的完全一样,请在提交时使用 --cleanup=verbatim 选项。 有关详细信息,请参阅 Git 文档中的 --cleanup=<mode>

检查状态和结论

检查可以具有许多不同的状态。 状态描述了检查从创建到完成时的状态。 某些状态无法手动设置,并且为 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 中的依赖检查的成功。
staleGitHub 将检查运行标记为过时,因为它花费的时间太长。
success检查运行已成功完成。
timed_out检查运行超时。

检查的保留

站点管理员可以控制 你的 GitHub Enterprise Server 实例 上的检查数据的保留策略。 有关详细信息,请参阅“配置应用程序”。

要将拉取请求与必需且已存档的检查合并,必须重新运行检查。