在 GitHub Actions 中，concurrency 是一个相对较新的配置选项，它允许你控制工作流的并发执行行为。你提供的代码片段配置了 并发控制 的相关设置，下面我来详细解释一下这段配置的含义和作用。

配置解析

1concurrency:
2  group: ${{ github.workflow }}-${{ github.ref_name }}
3  cancel-in-progress: true

1. group: ${{ github.workflow }}-${{ github.ref_name }}

• group 是用来定义并发组的名称，它决定了哪些工作流运行在同一个并发组下。每个工作流运行时，都会被分配到某个组内。
• github.workflow：代表当前工作流的名称。
• github.ref_name：代表当前触发工作流的 Git 参考名称（如分支名或者标签名）。

这样设置的目的是确保同一个工作流在同一个分支上，或者同一个工作流在某个特定的分支或标签上运行时，会被归入同一个并发组。即使有多个工作流被触发，它们也会按照这个规则共享并发资源。

举个例子：

• 假设有两个分支 main 和 feature，同时触发了名为 CI 的工作流。
• 这样，group 就会分别是：
  • CI-main （对于 main 分支）
  • CI-feature （对于 feature 分支）
• 这确保了同一个分支上的多个工作流会被视为一个组，避免了不同分支间的并发冲突。

2. cancel-in-progress: true

• cancel-in-progress 表示如果有一个同一并发组内的工作流正在运行，那么如果该组中有新的工作流被触发，就会取消正在进行的工作流。
• 这有助于减少资源浪费，尤其是在一些情况中，旧的工作流可能不再需要（例如，你只关心最新的提交），通过取消正在进行的工作流，能够更高效地利用 CI/CD 系统资源。

实际例子：

假设你有一个 GitHub Actions 配置文件，使用 concurrency 来确保在同一个分支上，只有最新的构建任务会运行，而不必等待旧的构建完成。

1name: CI Workflow
2
3on:
4  push:
5    branches:
6      - main
7      - feature/*
8
9concurrency:
10  group: ${{ github.workflow }}-${{ github.ref_name }}  # 根据工作流名和分支名进行分组
11  cancel-in-progress: true  # 取消正在进行的相同组中的工作流
12
13jobs:
14  build:
15    runs-on: ubuntu-latest
16
17    steps:
18      - name: Checkout code
19        uses: actions/checkout@v2
20
21      - name: Set up Node.js
22        uses: actions/setup-node@v2
23        with:
24          node-version: '14'
25
26      - name: Run tests
27        run: npm test

工作原理：

• 当在 main 分支上推送新的提交时，GitHub Actions 会触发工作流，并且所有 main 分支的构建都会被分到同一组 CI-main 中。如果之前有一个 main 分支的构建正在运行，新的构建会取消掉旧的构建。
• 同理，对于 feature/* 分支，新的推送会取消正在进行的 feature/* 分支构建，确保同一分支只会有一个工作流正在运行。

总结：

通过 concurrency 配置，你可以：

• 控制工作流是否允许并发执行。
• 设置同一个并发组内的工作流相互排斥（通过 cancel-in-progress: true），避免多个相同工作流的冗余执行。

这对 CI/CD 系统尤其重要，能帮助节省时间和资源，提高效率，避免不必要的重复构建。