GitLab CI如何根据手动选择的环境动态引入配置文件？

你的问题核心在于：GitLab CI的include指令是在配置解析/校验阶段执行的，而手动触发时选择的流水线变量（比如$DEPLOY_ENVIRONMENT）要到流水线运行阶段才会被注入，因此解析阶段无法获取变量值，导致路径解析错误。

下面提供两种可行的解决办法：

方案一：带规则判断的多Include（适用于文件固定存在的场景） #

如果production/configurations.yml和staging/configurations.yml两个文件都已存在，可以给每个include添加rules条件，让GitLab根据变量值决定引入哪个文件：

stages:
 - build
 - deploy
 
variables:
  DEPLOY_ENVIRONMENT:
    value: "production"
    options:
      - "production"
      - "staging"
    description: "The deployment target. Set to 'production' by default."
  DEPLOY_COLOUR:
    value: "blue"
    options:
      - "blue"
      - "green"
    description: "The deployment colour. Set to 'blue' by default."    
  DEPLOY_VERSION:
    value: ""
    description: "The deployment version. e.g. 1.0.0 for production && 1.0.0-rc for staging."   
  DEPLOY_APPLICATION:
    value: "app1"
    options:
      - "app1"
      - "app2"
    description: "The application to deploy"   

# 按环境条件引入对应配置文件
include: 
  - local: 'production/configurations.yml'
    rules:
      - if: '$DEPLOY_ENVIRONMENT == "production"'
  - local: 'staging/configurations.yml'
    rules:
      - if: '$DEPLOY_ENVIRONMENT == "staging"'

Update_GIT:
  stage: build
  # 你的任务逻辑...

注意：这种方式要求两个配置文件必须都存在，否则GitLab在初始配置校验时会报错找不到文件。

方案二：使用Child Pipeline（更灵活，无文件存在性预校验要求） #

通过生成动态的子流水线配置文件，绕开初始解析阶段的变量限制：

stages:
  - generate_config
  - build
  - deploy
 
variables:
  DEPLOY_ENVIRONMENT:
    value: "production"
    options:
      - "production"
      - "staging"
    description: "The deployment target. Set to 'production' by default."
  # 其他变量保持不变...

# 第一步：根据选择的环境生成子流水线配置
generate_child_config:
  stage: generate_config
  script:
    # 生成包含对应环境配置的子CI文件
    - echo "include: ['$DEPLOY_ENVIRONMENT/configurations.yml']" > child-ci.yml
  artifacts:
    paths:
      - child-ci.yml

# 第二步：触发子流水线，执行实际部署逻辑
deploy_via_child:
  stage: deploy
  trigger:
    include:
      - artifact: child-ci.yml
        job: generate_child_config
    strategy: depend

原理：子流水线的配置文件是在运行阶段动态生成的，此时已经能获取到手动传入的$DEPLOY_ENVIRONMENT变量，因此可以正确引入对应环境的配置文件。这种方式无需提前让GitLab校验所有可能的配置文件，灵活性更高。

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