GitHub Actions 怎样为工作流设置并发取消策略

如果一个分支连续推送三次，GitHub Actions 默认会让多次运行同时排队或执行，测试和构建资源很快就被旧提交占满。我的做法是先用 concurrency.group 划定“哪些运行互相影响”，再决定是否用 cancel-in-progress 取消旧运行。这样开发分支可以只保留最新提交，发布分支则继续保留完整流水线。

官方地址：https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax

先把并发组边界划对

concurrency 可以放在工作流顶层，也可以放在 jobs. 下。顶层限制的是整条工作流，job 层只限制指定 job。实践中，测试工作流通常按“工作流名 + 分支”分组，避免 lint、构建和部署工作流因为写了同一个固定组名而互相取消。

name: CI

on:
  push:
    branches: [main, develop]

concurrency:
  # 用工作流名区分不同流水线，用 ref 区分不同分支
  group: ${{ github.workflow }}-${{ github.ref }}
  # 同组有新运行时，取消仍在执行的旧运行
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 运行测试
        run: go test ./...

这里的关键不是把表达式照抄，而是让 group 真正对应业务边界。GitHub 文档说明组名不区分大小写；同组最多保持一个运行中的任务，默认只保留一个 pending 任务。新运行到达时，旧的 pending 任务会被替换。若你需要多个运行排队，可以使用 queue: max，但它不能和 cancel-in-progress: true 同时使用。

让新提交接替同一分支的旧运行

对单元测试、静态检查和预览构建，cancel-in-progress: true 通常很合适：旧提交已经不再是最新代码，继续消耗 runner 只会延迟真正需要的结果。group 中要带上 github.workflow，否则同一仓库里的另一个工作流如果复用了相同分支字符串，也可能取消不属于自己的运行。

Pull Request 需要特别注意上下文。github.head_ref 只在 Pull Request 事件中定义；如果工作流同时响应 push，就应该给它一个回退值：

on:
  push:
    branches: [main]
  pull_request:

concurrency:
  # PR 使用源分支，push 没有 head_ref 时退回唯一 run_id
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  # 新提交到同一 PR 时，取消旧的检查运行
  cancel-in-progress: true

这个回退值的作用是避免不同事件下 group 变成空值或意外合并。若你只处理 push，也可以直接使用 github.ref；如果还要覆盖 PR，优先显式写出事件差异。

让开发分支取消，发布分支保留

部署是另一个判断：开发分支的预览环境通常可以追最新提交，但生产或 release 分支可能需要完整跑完测试、生成制品和记录审计结果。这时不必把所有运行都设成同一种取消方式，可以让 cancel-in-progress 接收表达式。

concurrency:
  # 工作流名和分支共同构成隔离边界
  group: ${{ github.workflow }}-${{ github.ref }}
  # release/ 分支保留运行，其它分支才取消旧运行
  cancel-in-progress: ${{ !startsWith(github.ref, 'refs/heads/release/') }}

判断结果时不要只看页面上有没有一个绿色运行。开发分支应能看到旧运行变为 Canceled，新运行继续执行；release 分支则不应因为新提交自动取消前一个运行。还要注意，取消运行不会替你撤销已经完成的外部副作用，所以生产部署仍需配合环境保护、幂等发布脚本和回滚方案。

配置后用三个状态确认结果

• 连续推送同一开发分支：旧运行应出现 Canceled，最新运行进入 In progress。
• 同时修改另一个工作流：它不应因为 group 中缺少 workflow 名而被误取消。
• 推送到 release/ 分支：按条件表达式检查是否保留完整运行；若需要排队，不要再叠加 cancel-in-progress。

一句话总结：group 决定谁属于同一竞争范围，cancel-in-progress 决定旧运行是否让位。先划清工作流、事件和分支边界，再按测试、预览、发布的副作用选择取消策略。

相关问题

concurrency 应该放在 workflow 还是 job？

需要整条流水线只保留最新运行时放在 workflow 层；只有某个 job 访问共享环境或资源时，才缩小到 job 层。

为什么新运行没有取消旧运行？

先看两个运行最终计算出的 group 是否相同，再检查 cancel-in-progress 是否为 true 或条件表达式是否返回 false。