GitHub Actions中concurrency是什么？请解释作业及工作流级别的运行机制

什么是 Concurrency？ #

GitHub Actions 里的 concurrency 就是用来限制同一时间内可运行的工作流/作业实例数量的配置项，核心是避免资源浪费、防止并发操作引发的冲突（比如同时部署同一环境导致的部署混乱），或是控制运行成本。

工作流级别（Workflow Level）的 Concurrency #

直接在工作流文件的最顶层配置，作用于整个工作流的所有实例，规则如下：

• 给工作流指定一个 concurrency 组（比如 prod-deploy-group）后，同一时间只有一个该组的工作流实例能处于运行状态。
• 当新的实例触发时，GitHub 会根据 cancel-in-progress 选项处理：
  • 如果设为 cancel-in-progress: true：直接取消正在运行的旧实例，启动新实例——适合代码提交触发的 CI/CD，优先跑最新代码的任务。
  • 如果设为 cancel-in-progress: false（默认值）：新实例会进入等待队列，等旧实例跑完再启动。
• 示例配置：

name: Deploy to Production
concurrency:
  group: prod-deploy-group
  cancel-in-progress: true
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Prod
        run: ./deploy-prod.sh

注意：工作流级别的 concurrency 不会强制覆盖作业级配置，但如果作业和工作流使用了同一个 concurrency 组名，作业会遵循工作流的并发规则。

作业级别（Job Level）的 Concurrency #

在单个 job 节点下配置，只对该作业的实例生效，不影响同一工作流里的其他作业，规则如下：

• 每个作业的 concurrency 组是独立的，哪怕和工作流用了不同的组名，互相之间也不会干扰。
• 同样支持 cancel-in-progress 选项，控制新实例触发时是否取消旧实例。
• 适用场景：比如某个耗时的集成测试任务，不想同时跑多个浪费资源；或是某个需要向同一数据库写入数据的作业，必须串行执行。
• 示例配置：

name: Build & Test Workflow
on:
  push:
    branches: [main, develop]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Project
        run: ./build.sh

  integration-test:
    runs-on: ubuntu-latest
    concurrency:
      group: integration-test-${{ github.ref }}
      cancel-in-progress: true
    steps:
      - uses: actions/checkout@v4
      - name: Run Integration Tests
        run: ./run-integration-tests.sh

这里用了动态组名 integration-test-${{ github.ref }}，意味着不同分支的集成测试任务不会互相阻塞，同一分支的测试则会优先跑最新的。

通用注意事项 #

• concurrency 组名可以是静态字符串，也可以用 GitHub 上下文变量动态生成，灵活适配不同分支、环境的需求。
• 被取消的实例会被标记为 Cancelled 状态，不会计入工作流的成功/失败统计，但运行记录会保留。
• 手动触发的工作流也会遵守 concurrency 规则，除非你在触发时通过高级选项覆盖配置。

内容的提问来源于stack exchange，提问作者Alexander