GitLab CI如何通过遍历数组生成多环境对应独立作业？

原生支持的批量作业能力 #

GitLab 13.3及以上版本官方提供了parallel:matrix关键字，完全可以实现类似Ansible循环的批量作业生成效果，也是当前这类场景的最佳实践方案。
该特性会基于你定义的变量矩阵自动生成多个独立作业，每个作业的变量、环境配置、runner标签都可以单独匹配，完美支持GitLab environments所有原生特性，也能调度到对应标签的runner。
配置示例如下：

test:all:
  stage: test
  parallel:
    matrix:
      - VERSION: ["v1.0", "v2.0", "v2.5"]
  environment:
    name: $VERSION
  tags:
    - $VERSION
  script:
    - ./run.sh $VERSION

提交配置后，流水线会自动生成3个独立的测试作业，分别对应三个版本环境，无需重复编写作业配置。

低版本GitLab替代方案 #

如果你使用的GitLab版本低于13.3，不支持parallel:matrix，可以采用以下社区常用方案：

• 使用YAML锚点和别名简化重复配置，公共逻辑仅需定义一次，后续修改也只需要调整公共部分：

  .test_base: &test_base
    stage: test
    script:
      - ./run.sh $VERSION
  
  test:v1.0:
    <<: *test_base
    environment:
      name: v1.0
    tags:
      - v1.0
    variables:
      VERSION: v1.0
  
  test:v2.0:
    <<: *test_base
    environment:
      name: v2.0
    tags:
      - v2.0
    variables:
      VERSION: v2.0
  
  test:v2.5:
    <<: *test_base
    environment:
      name: v2.5
    tags:
      - v2.5
    variables:
      VERSION: v2.5
  

• 动态生成CI配置：在流水线触发阶段运行脚本，根据环境列表动态生成完整的.gitlab-ci.yml内容，配合父/子流水线特性加载生成的配置，也可以实现批量生成作业的效果。
• 拆分配置文件：将公共配置存放在主CI文件，每个环境的作业单独拆分为小的YAML文件，通过include关键字批量导入，适合环境数量较多的场景。

你提到的单作业内部循环遍历版本的方案确实不推荐，无法实现环境、runner标签的绑定，也不能使用environments的追踪、回滚等特性。

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