如何解决GitLab流水线中变量无法实时修改及规则预执行的问题？

在GitLab CI/CD流程中，依赖Variables传递参数时经常遇到两个核心问题：

• 无法实时修改变量：如果需要基于前置作业的输出调整后续作业逻辑，只能将结果存入缓存，无法直接写入CI/CD变量
• 作业规则预评估：rules块的判断逻辑在流水线启动前就已完成，只会使用初始参数值，运行时生成的参数无法触发规则变更

针对这类场景（比如数据产品交付时需要根据内容自动选择测试环节），可以用以下方案临时解决：

1. 运行时修改自定义CI/CD变量 #

通过GitLab项目级变量API可以在流水线运行时操作自定义CI/CD变量（注意：仅支持自定义变量，YML文件头部variables块定义的变量无法通过此方式修改）。只需要拥有带API访问权限的PRIVATE-TOKEN，就能完成变量的创建、修改或删除。

示例脚本：

job:
  stage: example
  script:
    - 'curl --request PUT --header "PRIVATE-TOKEN: $ACCESS_TOKEN" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/variables/VARIABLE_NAME" --form "value=abc"'

2. 解决rules预评估问题 #

直接修改变量无法控制下游作业的执行，因为rules的判断在流水线启动阶段就已完成，会使用变量修改前的值。比如下面的作业不会触发，哪怕前置作业已经把VARIABLE_NAME改成了abc：

job2:
  stage: after_example
  rules:
    - if: $VARIABLE_NAME == "abc"
  script:
    - env

解决这个问题的核心是使用子流水线：子流水线在父流水线运行过程中初始化，会重新检查当前的环境变量状态，从而实现基于运行时变量的规则判断。

完整示例 #

父流水线（.gitlab-ci.yml）

variables:
  PARAMETER: "Cant be changed"

stages:
  - example
  - after_example
  - finally

job_1:
  # 运行时将已存在的自定义变量VARIABLE_NAME修改为abc
  stage: example
  script:
    - 'curl --request PUT --header "PRIVATE-TOKEN: $ACCESS_TOKEN" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/variables/VARIABLE_NAME" --form "value=abc"'

job_2.1:
  # 不会触发：rules在流水线启动时评估，此时VARIABLE_NAME尚未被修改
  stage: after_example
  rules:
    - if: $VARIABLE_NAME == "abc"
  script:
    - env

job_3:
  stage: after_example
  trigger:
    include:
      - local: .downstream.yml
    strategy: depend

job_4:
  stage: finally
  script:
    - echo "记得将变量恢复到默认值，避免影响后续流水线"

下游子流水线（.downstream.yml）

stages:
  - downstream

job_2.2:
  # 会触发：子流水线在job_1执行后初始化，此时VARIABLE_NAME已更新为abc
  stage: downstream
  rules:
    - if: $VARIABLE_NAME == "abc"
  script:
    - env

逻辑说明 #

• job_2.1不会执行：因为它的rules在流水线启动前就完成了评估，那时VARIABLE_NAME还不是abc
• job_2.2会执行：子流水线在job_1完成后才初始化，此时变量已更新，rules会基于最新值判断

这个方案属于临时 workaround，效率不算最优，但能满足复杂流水线中基于运行时动态参数控制作业执行的需求。

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