自动取消冗余运行
同一分支连续推送时取消未运行的旧流水线：省资源、缩短反馈，避免旧提交的结果淹没新提交。与互斥排队不同，这是保留最新、丢弃陈旧的策略：新运行取消旧运行，只关心最新一次的结果。发布类作业通常不参与取消，避免留下半发布状态；被取消的运行带专门标记，统计时要与失败区分。
基本信息
| GitLab | 作业级 interruptible: true 配合项目级自动取消设置 |
|---|---|
| GitHub | concurrency 加 cancel-in-progress: true |
| 注意 | 发布类作业不标记可中断，避免半发布状态 |
| 标记 | 被取消的运行有专门状态，与失败区分统计 |
| 范围 | 按环境与分支选择作用范围，避免误伤 |
典型使用场景
- 高频推送分支：修复过程中连续提交，只关心最新一次。
- 文档分支：非关键变更不占用并发额度。
- 资源紧张：自动释放排队中的旧运行。
- 流水线风暴：机器人连续推送时防止排队堆积。
GitLab
GitLab
test:
interruptible: true
script: npm testGitHub
GitHub
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true两种机制对照
| 机制 | 行为 |
|---|---|
| cancel-in-progress | 新运行取消旧运行 |
| resource group | 旧运行继续、新的排队等待 |
| 组合配置 | 测试可取消、部署不取消 |
部署中作业不要标记可中断：中断后的环境状态需要人工核对。
取消要留痕：被取消的运行要与失败区分解释，否则团队会误读反馈面板。
作用范围收窄：并发组按分支或环境命名，避免跨分支误取消无关流水线。
与缓存配合的特殊性：被取消的分片可能没完成缓存上传，缓存预热交给独立作业更稳。
取消策略每季度复核：分支模型与工具变化后，原本合理的取消范围可能不再适用。
新旧流水线抢同一环境：取消只解决排队问题，环境互斥仍要靠资源组兜底。