Gitlab-CI单阶段并行任务数量限制及配置疑问咨询

针对你需要在单阶段内限制最多2个并行任务的场景，GitLab CI内置的resource_group特性完全可以满足需求，它能控制同一时间内运行的任务数量，且任务会按顺序排队执行——不管之前的任务成功还是失败，后续任务都会在有空闲slot时启动。

具体配置示例 #

你可以通过定义模板复用配置，让3个任务共享同一个资源组限制：

stages:
  - build

# 定义构建任务模板，统一配置资源组限制
.build_job_template:
  stage: build
  # 指定资源组名称，用于标识需要限制的任务集合
  resource_group: external_build_service
  # 设置最大并发数为2，对应外部服务的slot数量
  resource_group_max_concurrency: 2
  script:
    - # 这里替换为调用外部构建服务的实际命令

# 三个具体构建任务，继承模板配置
build_task_1:
  extends: .build_job_template
  script:
    - echo "执行构建任务1"
    - # 你的构建命令

build_task_2:
  extends: .build_job_template
  script:
    - echo "执行构建任务2"
    - # 你的构建命令

build_task_3:
  extends: .build_job_template
  script:
    - echo "执行构建任务3"
    - # 你的构建命令

配置说明 #

• resource_group：给需要限制的任务标记同一个资源组名称，GitLab会基于这个分组控制并行数。
• resource_group_max_concurrency: 2：明确该资源组同一时间最多允许2个任务运行，第三个任务会进入排队状态，直到有任务完成（无论成功或失败）才会启动。

关于你提到的其他方案的说明 #

1. needs不适用：needs的作用是定义跨阶段的任务依赖，让某个任务提前执行，无法控制同一阶段内的任务并行数量，也无法实现失败后仍继续执行后续任务的排队逻辑。
2. rules无法实现：rules只能基于流水线变量、分支、标签等静态条件判断是否执行任务，无法实时检测当前阶段正在运行的任务数量，因此没法用来动态限制并行数。

额外注意事项 #

• 确保你的GitLab版本在13.10及以上（resource_group_max_concurrency是这个版本引入的特性）。
• 如果其他流水线也需要使用这个外部构建服务，建议给资源组设置唯一的resource_group_key，避免不同流水线之间互相影响。

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