GitLab CI/CD中.common配置块如何引用全局variables变量

• 没法直接把全局variables里定义的env变量传入.common这类全局复用配置块当静态值用，你之前写&env_tag $env失败根本不是语法写错了，是GitLab CI的解析流程机制决定的。

操作失败的本质原因 #

GitLab CI的配置加载是严格按两个互不交叉的阶段顺序执行的：

1. 第一阶段：纯YAML语法解析。这一步会完成YAML结构校验、锚点定义与引用、.common这类隐藏模板块的提取、extends字段的模板拼接。这个阶段GitLab完全不会识别、替换你定义的CI变量，所有写在YAML结构里的文本都会被当成纯静态字符串处理。
2. 第二阶段：CI变量注入替换。只有等第一阶段的YAML结构全部拼接完成，形成最终的job配置列表后，GitLab才会把全局variables、项目设置变量、流水线触发传入的变量值，替换到对应位置的$变量名字符串上。

你之前在.common块里写$env，是在第一阶段就被当成静态文本存入了模板，根本等不到第二阶段的变量替换流程，最后实际生效的标签值就是字面的$env，而不是你定义的prod。

可行的实现方案 #

• 方案1：把变量引用位置从模板块移到实际执行的job层级
  不要在.common里硬写带变量的标签，只把通用的、不需要动态替换的逻辑放在.common里，需要动态引用全局env变量的tags配置，直接写在每个继承了.common的实际job里，这个位置是在第二阶段才会被解析的，能正常拿到变量值。
  参考写法：

  variables:
    name: app
    env: prod
  
  .common:
    # 模板里只放通用静态逻辑
    script:
      - echo "current deploy env is $env"
  
  # 实际执行的job
  deploy_prod:
    extends: .common
    tags:
      - "$env" # 这里的变量引用能被正常识别，替换为prod
  

• 方案2：如果不需要动态切换env值，直接用YAML原生锚点传递固定值
  如果你的生产环境标签值是固定的prod，根本不需要借助CI变量做替换，直接在.common块里用YAML原生锚点固定值即可，完全不涉及CI变量的解析流程：

  .common:
    tags:
      - &env_tag prod # YAML解析阶段就直接确定值为prod，无后续变量替换流程
  

• 方案3：需要动态切换env值时，用rules配合job级变量做匹配
  如果你需要根据流水线分支、触发来源自动切换不同环境的标签值，可以在实际job里通过rules规则动态给env赋值，再把标签和变量绑定：

  .common:
    script:
      - echo "start deploy"
  
  deploy_job:
    extends: .common
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"'
        variables:
          env: prod
      - if: '$CI_COMMIT_BRANCH == "staging"'
        variables:
          env: staging
    tags:
      - "$env"
  

注意：任何在全局隐藏模板块（以.开头的无独立执行逻辑的配置块）里写的变量引用，都会被第一阶段的YAML解析当成静态文本，无法触发后续的CI变量替换，这是整个机制的核心限制，没有其他语法可以绕开。

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