摘要

  • 并发组控制解析为同一组键的作业或工作流运行；等待、替换和取消取决于该组的配置。
  • GitHub 明确说明并发与环境并不会自动关联。
  • 关于部署已串行化的结论，需要有效组键、成员与处置、执行记录和独立的目标观察。

“生产已经串行化”有时只是调度意图，而非目标系统的观察。GitHub Actions 可为工作流或作业声明并发组。它能阻止解析为同一键的已命名工作平行运行，替换等待中的运行，或在显式选择队列时保留更多等待工作。这是有价值的调度控制，但它只覆盖实际解析到这把键的运行；没有使用这把键的工作流不会自动纳入。

处置状态不能混为一谈。GitHub 说明，通常一个组中可以有一项运行和一项等待，后来的候选项可以替换原来的等待项。queue: max 会保留受限队列，cancel-in-progress: true 则可取消正在运行的工作。某项处于等待状态，不证明之前的等待仍存在；某项被取消，也不说明它在取消之前是否已发出外部调用、发布制品或改变目标。

顺序也不能从触发时间直接得出。GitHub 描述的 FIFO 是按照运行开始等待的时间，而不是工作流被分派的时间，并提醒实际开始时间可能变化。要断言顺序，必须保留展开后的组表达式和键、相关作业或运行的成员关系、等待、开始和结束时间，以及源修订和制品身份。一个组标签无法补足这些记录。

环境边界尤其值得分开。GitHub 表示并发与环境没有连接：并发值可以是任何字符串，另一工作流即使使用同一环境，只要没有指定这一组，就不受其规则约束。环境保护规则和并发规则可以同时存在，却各自独立。并发键不是环境的通用锁，环境也不会替并发键自动扩大范围。

并发组 REST API 可以显示活跃成员及其 pending 或 in progress 状态。这是对平台当下状态的有用观察，并非完整的目标状态记录。Daniel Kade 建议保存组表达式和展开键、队列与取消政策、成员和时间、提交与不可变制品、环境选择、执行记录以及具有方法和时间的目标观察。敏感细节可受保护，缺少的连接不能由一个安心的组名代填。

来源

  1. GitHub Docs — Concurrency
  2. GitHub Docs — Workflow syntax
  3. GitHub Docs — Deploying with GitHub Actions
  4. GitHub Docs — Actions concurrency groups REST API