关于状态检查

状态检查可让您了解您的提交是否满足您正在为其贡献的存储库设置的条件。

本文内容

状态检查基于外部进程（例如持续集成构建），这些进程会在您对存储库进行每次推送时运行。您可以在拉取请求中各个提交旁边看到状态检查的 *待定*、*通过* 或 *失败* 状态。

Screenshot of a list of commits and statuses.

任何对存储库具有写入权限的用户都可以设置存储库中任何状态检查的状态。

您可以在存储库的分支页面或存储库的拉取请求列表中查看分支的最后一次提交的总体状态。

如果存储库需要状态检查，则在将您的分支合并到受保护的分支之前，必须通过必需的状态检查。有关更多信息，请参阅“关于受保护的分支”。

注意

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

GitHub 上的状态检查类型

GitHub 上有两种状态检查类型

  • 检查
  • 提交状态

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

注意

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

组织所有者和对存储库具有推送访问权限的用户可以使用 GitHub 的 API 创建检查和提交状态。有关更多信息，请参阅“检查的 REST API 端点”和“提交状态的 REST API 端点”。

检查

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

注意

仅当您为存储库设置了检查（而不是提交状态）时，“检查”选项卡才会填充拉取请求。

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

您可以使用拉取请求中“**检查**”选项卡下的提交下拉菜单在不同提交的检查摘要之间导航。

Screenshot of the "Checks" tab of a pull request. The "Checks" tab and the dropdown menu to select a commit are both outlined in dark orange.

跳过和请求单个提交的检查

当存储库设置为自动请求推送的检查时，您可以选择跳过您推送的单个提交的检查。当存储库未设置为自动请求推送的检查时，您可以请求您推送的单个提交的检查。有关这些设置的更多信息，请参阅“检查套件的 REST API 端点”。

您还可以通过在提交消息中包含命令来跳过由push和pull_request事件触发的 workflow 运行。有关更多信息，请参阅“跳过 workflow 运行”。

或者，要跳过或请求提交的所有检查，请在提交消息的末尾添加以下尾部行之一

  • 要跳过提交的检查，请键入您的提交消息和对更改的简短、有意义的描述。在提交描述之后，在结束引号之前，添加两行空行，然后添加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 会保留 400 天的检查数据。400 天后，数据将被存档。存档 10 天后，数据将被永久删除。

要合并具有同时需要和已存档的检查的拉取请求，您必须重新运行检查。