如何在推送事件中跳过 GitHub Actions 作业？

Posted 2023-02-18

【中文标题】如何在推送事件中跳过 GitHub Actions 作业？

【英文标题】：How to skip GitHub Actions job on push event?

【发布时间】：2020-05-02 17:20:05

【问题描述】：

使用 Travis CI，我们可以通过向提交添加后缀来跳过特定提交的构建。这在Travis CI 中有描述。当我只编辑与代码无关的README.md 并且不需要触发飞行前构建时，我发现此功能很实用。

[skip ci]

如何使用 GitHub Actions 跳过触发 on: push 事件的作业？

name: Maven Build
on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - name: Check-out project
      uses: actions/checkout@v1
    - name: Set up JDK 11.0.3
      uses: actions/setup-java@v1
      with:
        java-version: 11.0.3
    - name: Build with Maven
      run: mvn -B package --file pom.xml

---

答案总结：

非常感谢所有提供各种方法来实现它的回答者。我敢打赌，对于问题的根源和 CI 方法，每个人都需要一些不同的东西。以下是为快速导航列出的答案：

在readme.md 文件上跳过 CI：https://***.com/a/61876395/3764965 在[skip ci] 上跳过 CI 作为新的 GitHub 功能： https://***.com/a/66156840/3764965（在这里回答） https://***.com/a/66114678/3764965（在另一个问题中回答） 通过解析跳过[skip ci]消息上的CI（可定制的解决方案）： https://***.com/a/59775665/3764965 允许每个特定分支的 CI：https://***.com/a/61876395/3764965

^{所有答案都值得点赞！如果你喜欢我的问题，你应该双重喜欢答案。}

【问题讨论】：

相关：How to skip all steps at once?

github.com/fkirc/skip-duplicate-actions 是一个简单的第三方解决方案，可在 GitHub 的原生解决方案不够强大或不够灵活的情况下提供帮助

新的（2021 年 2 月）[skip ci] 提交消息策略也很有趣：***.com/a/66114678/6309

@VonC：这是一个很棒的功能！你可以在这里回答。我已将您的答案链接到我的问题摘要中，因为我发现它非常有帮助。谢谢！

@NikolasCharalambidis 否：它基于提交消息，而您的问题更多基于文件，如果我没记错的话。

【参考方案1】：

更新：请接受 Helmisek anwser，它指出 Github 具有 built-in now 的功能。

如果您只想跳过一些工作/步骤，我的回答才有意义。

---

您可以尝试以下方法：

name: Maven Build
on: [push]

jobs:
  build:
    if: "!contains(github.event.commits[0].message, '[skip ci]')"
    runs-on: ubuntu-latest

    steps:
    - name: Check-out project
      uses: actions/checkout@v1
    - name: Set up JDK 11.0.3
      uses: actions/setup-java@v1
      with:
        java-version: 11.0.3
    - name: Build with Maven
      run: mvn -B package --file pom.xml

【讨论】：

if: "! contains(toJSON(github.event.commits.*.message), '[skip-ci]')"

当特定提交不应该触发 CI 管道时，无论内容如何，​​此答案都非常有用。感谢您的回答，+1。​​\

你能举一个 git commit 命令的例子来跳过这个动作吗？

【参考方案2】：

截至目前（2021 年 2 月）GitHub 操作默认支持此行为。默认情况下不再需要解析等。

见：

GitHub Actions：使用[skip ci]跳过拉取请求和推送工作流

GitHub Actions 现在支持跳过 push 和 pull_request 工作流程 通过在您的提交消息中查找一些常见的关键字。

如果您的推送或 PR 的 HEAD 提交中有任何提交消息 包含字符串[skip ci]、[ci skip]、[no ci]、[skip actions] 或 [actions skip] push 或 pull_request 事件触发的工作流 将被跳过。

链接：Github Actions Changelog, February 2021

【讨论】：

我刚刚试了一下，效果还不错。例如chore: build script update [skip ci]，它被跳过了。

【参考方案3】：

此外，对于您希望在所有推送中忽略的文件和目录you can configure the workflow 本身：

on:
  push:
    paths-ignore:
    - 'README.md'

【讨论】：

这确实解决了我的问题，因为我的问题有点像 XY。

【参考方案4】：

Git 2.27（2020 年第二季度）展示了另一种方法：用户可以指定要构建的哪些分支，而不是总是通过 Actions 在 GitHub 上构建所有分支。

参见Jeff King (peff) 的commit e76eec3（2020 年 5 月 7 日）。^{（由 Junio C Hamano -- gitster -- 合并到 commit dd4a287，2020 年 5 月 13 日）}

ci：允许 GitHub Actions 的每个分支配置

^{签字人：杰夫·金}

根据各个开发人员的工作流程，我们的 GitHub Actions CI 作业在每个分支上运行可能很方便，也可能很烦人。

作为一个烦人的例子：如果你携带许多半完成的工作分支并经常将它们与 master 进行 rebase，你会得到大量不有趣的失败报告（更不用说浪费的 CPU） .

此提交添加了一个新作业，该作业检查存储库中的一个特殊分支以获取 CI 配置，然后运行它找到的 shell 脚本来决定是否跳过其余的测试。

如果缺少该分支或脚本，默认将继续为所有 ref 运行测试。

已经讨论了一些替代方案：

一种选择是在提交本身中携带有关是否应该对其进行测试的信息，无论是在树本身（更改工作流程 YAML 文件）还是在提交消息中（“[skip ci]”标志或类似标志）。但是这些使用起来令人沮丧且容易出错：

您必须手动将它们应用于您要标记的每个分支 他们很容易泄漏到其他工作流程中，例如通过电子邮件发送补丁

我们同样可以尝试从分支名称中获取一些信息。但这导致了关于默认值应该是“关闭”还是“打开”的争论，并且覆盖最终仍然有些尴尬。 如果我们默认为“on”，您必须记住适当地命名您的分支以跳过 CI。 如果“关闭”，您最终将不得不扭曲您的分支名称或使用额外的 refspec 复制您的推送。

相比之下，此提交的解决方案让您只需指定一次配置就可以忘记它，并且所有数据都在其自己的 ref 中关闭，可以通过单独的 fork 更改而不接触主树。

有一些设计决策来自列表讨论。我在这里总结一下：

我们可以使用 GitHub 的 API 来检索配置引用，而不是真正的结帐（然后只需通过一些 javascript 对其进行操作）。 无论哪种方式，我们仍然需要启动一个 VM 并通过网络与 GitHub 联系，因此最终速度不会快多少。 我选择使用 shell 来保持与我们其他工具相似的东西（并且真的可以用任何你想要的语言实现 allow-refs）。这也便于在本地测试您的脚本，并在普通 git.git 树的上下文中对其进行修改。

我们可以将众所周知的引用名排除在refs/heads/ 之外，以避免混淆分支命名空间。但这使得操纵起来很尴尬。 相比之下，您只需“git checkout ci-config”即可进行更改。

我们可以假设 ci-config 引用除了配置（即与 git.git 的其余部分无关的分支）之外什么都没有。 但是处理孤儿分支很尴尬。相反，我们将尽最大努力使用浅部分克隆仅有效地检查 ci/config 目录，这允许您的 ci-config 分支只是一个普通分支，而您的配置更改位于顶部。

我们可以提供一个更简单的界面，例如引用模式的静态列表。 但无论如何我们都无法摆脱启动整个 VM 的问题，因此我们不妨使用该功能使配置尽可能灵活。 如果我们添加更多配置，我们应该能够重用我们的部分克隆来设置更多输出。

所以脚本是ci/config/allow-refs.sample:

#!/bin/sh
#
# Sample script for enabling/disabling GitHub Actions CI runs on
# particular refs. By default, CI is run for all branches pushed to
# GitHub. You can override this by dropping the ".sample" from the script,
# editing it, committing, and pushing the result to the "ci-config" branch of
# your repository:
#
#   git checkout -b ci-config
#   cp allow-refs.sample allow-refs
#   $EDITOR allow-refs
#   git commit -am "implement my ci preferences"
#   git push
#
# This script will then be run when any refs are pushed to that repository. It
# gets the fully qualified refname as the first argument, and should exit with
# success only for refs for which you want to run CI.

case "$1" in
# allow one-off tests by pushing to "for-ci" or "for-ci/mybranch"
refs/heads/for-ci*) true ;;
# always build your integration branch
refs/heads/my-integration-branch) true ;;
# don't build any other branches or tags
*) false ;;
esac

the action .github/workflows 所要做的就是

检查特殊分支和其中的特殊脚本：

即：

git -c protocol.version=2 clone \
  --no-tags \
  --single-branch \
  -b ci-config \
  --depth 1 \
  --no-checkout \
  --filter=blob:none \
  https://github.com/$ github.repository  config-repo \
&& \
cd config-repo \
&& \
git checkout HEAD -- ci/config

检查推送的分支是否授权：

这是：

enabled=yes
if test -x config-repo/ci/config/allow-ref &&
         ! config-repo/ci/config/allow-ref '$ github.ref '
then
  enabled=no
fi