这个问题的核心在于GitLab CI处理变量的两个不同阶段——你在rules里引用的变量和脚本里引用的变量，被解析的时机完全不一样，导致$FOO在规则评估时并不是你预期的值。

为什么原配置正常，修改后失效？ #

GitLab CI的变量处理分为两个关键阶段：

1. 流水线创建阶段：GitLab会先评估rules、生成整个流水线的结构。此时它会解析预定义变量、项目/组级变量、全局变量，以及job级中直接赋值的字符串变量（比如你的PUSH: "push"）。
2. Job执行阶段：当具体的job开始运行时，才会解析那些依赖其他变量的job级变量（比如你的FOO: $PUSH）。

所以在你修改后的rules:if: '$CI_PIPELINE_SOURCE == $FOO'中：

• 评估规则时，$FOO还没有被插值为"push"，它的当前值就是字面量字符串$PUSH（因为FOO是引用PUSH的变量，要到job执行时才会被替换）。
• 此时条件实际变成了"push" == "$PUSH"，显然不相等，所以job不会被触发。

而原配置中的rules:if: '$CI_PIPELINE_SOURCE == $PUSH'能正常工作，是因为PUSH是直接赋值的字符串"push"，在流水线创建阶段就已经被解析为实际值，条件变成"push" == "push"，自然成立。

验证这个结论 #

你可以快速验证这个逻辑：

1. 修改job级变量，把FOO直接赋值为"push"：

   variables:
     PUSH: "push"
     FOO: "push" # 不再引用PUSH，直接赋值
   

2. 保持rules:if: '$CI_PIPELINE_SOURCE == $FOO'并推送代码，此时流水线会正常触发——因为FOO的值在规则评估阶段就已经是"push"了。

解决方法 #

如果需要在rules中使用依赖其他变量的变量，你有几个可行的方案：

• 直接写目标值：在rules里直接用'$CI_PIPELINE_SOURCE == "push"'，跳过变量引用，最直接简单。
• 把变量移到全局：将PUSH和FOO定义为全局variables（放在job块外面），这样它们会在流水线创建阶段被完整解析，rules可以正常引用：

  variables:
    PUSH: "push"
    FOO: $PUSH
  
  job:
    stage: cool-stage
    rules:
      - if: '$CI_PIPELINE_SOURCE == $FOO'
        when: always
    script:
      # ... 你的脚本内容
  

• 使用模板复用：用GitLab的extends或锚点语法来复用变量定义，确保变量在规则评估时已完成解析。

补充：为什么脚本里的变量正常？ #

你脚本中的$FOO能正确输出"push"，是因为脚本是在job执行阶段运行的，此时FOO已经完成了对PUSH的插值。这个阶段和rules的评估阶段完全独立，所以才会出现"脚本里变量正常，但rules里不生效"的矛盾现象。

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