GitLab CI配置gitlab-ci.yml是否支持嵌套使用!reference？

GitLab CI 不支持嵌套使用!reference标签，这是官方明确的功能限制：!reference仅做单层解析，不会递归处理引用目标内部嵌套的其他!reference节点，这也是触发jobs:a_pybuild:only changes should be an array of string报错的根本原因——嵌套的!reference没有被展开，最终传入changes字段的内容包含未解析的YAML标签节点，不是纯字符串数组。

以下是三种合规可落地的实现方案：

方案1：单层引用拼接（改动最小、最适配原需求） #

不要在rules.yml的子规则里嵌套!reference，保留公共default规则的独立定义，把各模块专属路径也拆成独立配置项，在作业配置时直接拼接多个单层!reference即可，完全符合语法规范。

修改rules.yml配置：

.rules:
  default:
    - .gitlab-ci.yml
    - Makefile
    - VERSION
  a_pybuild_extra:
    - foo/a/**
  b_pybuild_extra:
    - foo/b/**

对应gitlab-ci.yml配置：

include:
  - local: "./rules.yml"

a_pybuild:
  stage: py_build
  script:
    - echo "build a"
  only:
    changes:
      - !reference [.rules, default]
      - !reference [.rules, a_pybuild_extra]

b_pybuild:
  stage: py_build
  script:
    - echo "build b"
  only:
    changes:
      - !reference [.rules, default]
      - !reference [.rules, b_pybuild_extra]

方案2：隐藏模板+extends继承（适合复杂规则场景） #

把不同场景的规则封装成隐藏作业模板，通过GitLab CI原生的extends关键字做配置复用，适合规则关联逻辑多、需要批量复用作业配置的场景。

rules.yml配置示例：

# 公共构建基础模板
.pybuild_base:
  stage: py_build
  only:
    changes:
      - .gitlab-ci.yml
      - Makefile
      - VERSION

# a模块构建专属模板
.a_pybuild_template:
  extends: .pybuild_base
  only:
    changes:
      - !reference [.pybuild_base, only, changes]
      - foo/a/**

# b模块构建专属模板
.b_pybuild_template:
  extends: .pybuild_base
  only:
    changes:
      - !reference [.pybuild_base, only, changes]
      - foo/b/**

注意：extends默认对数组类型字段执行覆盖逻辑，上面示例中显式引用父模板的changes字段，才能实现公共规则+专属规则的数组合并效果。

对应gitlab-ci.yml配置：

include:
  - local: "./rules.yml"

a_pybuild:
  extends: .a_pybuild_template
  script:
    - echo "build a"

b_pybuild:
  extends: .b_pybuild_template
  script:
    - echo "build b"

方案3：YAML原生锚点（适合单文件内复用） #

如果不需要跨文件复用规则，可直接使用YAML标准的锚点、别名特性实现配置复用，不存在GitLab解析兼容问题。示例：

# 定义公共路径锚点
.rule_ci: &ci_file .gitlab-ci.yml
.rule_make: &make_file Makefile
.rule_version: &version_file VERSION

a_pybuild:
  stage: py_build
  script:
    - echo "build a"
  only:
    changes:
      - *ci_file
      - *make_file
      - *version_file
      - foo/a/**

该方案缺点是锚点作用域仅限定义它的文件，跨文件复用灵活性较差。

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