能否在已批准合并请求合并后，于main分支运行带MR预定义变量的CI/CD流水线？

核心结论 #

直接在main分支的push管道中读取$CI_MERGE_REQUEST_*预定义变量不可行——这类变量仅在merge_request_event类型的管道中生效，main分支的push管道属于push事件，无法直接获取MR的标题和描述信息。以下是两种满足需求的可行方案：

方案一：使用合并结果管道（推荐） #

利用GitLab的合并结果管道特性，让获批后的MR触发基于合并后代码的管道，既满足"仅在合并后逻辑等价于main分支执行CI"的要求，又能完整获取MR的预定义变量：

rules:
  # 禁止普通MR提交时触发CI，满足场景1
  - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    when: never
  # 仅在获批后的合并结果管道中触发，同时保留校验规则
  - if: >
      $CI_PIPELINE_SOURCE == "merge_request_event" &&
      $CI_MERGE_REQUEST_APPROVED &&
      $CI_MERGE_REQUEST_EVENT_TYPE == "merged_result" &&
      $CI_MERGE_REQUEST_TITLE =~ /^v\d+(\.\d+){2}$/ &&
      $CI_MERGE_REQUEST_DESCRIPTION != "" &&
      $CI_MERGE_REQUEST_DESCRIPTION =~ $MERGE_REQUEST_DESC_PATTERN
    when: always
    variables:
      # 提前将MR标题赋值为镜像标签变量，方便后续任务调用
      IMAGE_TAG: '$CI_MERGE_REQUEST_TITLE'

方案说明 #

1. 第一条规则直接禁用普通MR事件的管道触发，完全符合"开发者发起MR时不触发CI"的要求
2. 合并结果管道是基于MR合并后的代码快照运行，效果等同于代码合并到main分支后的执行
3. 该管道属于merge_request_event类型，$CI_MERGE_REQUEST_TITLE、$CI_MERGE_REQUEST_DESCRIPTION等变量全部可用，能完整保留校验逻辑
4. 需要提前在项目设置→CI/CD→流水线中开启合并结果管道功能

方案二：通过API传递MR信息到main分支管道（备选） #

如果无法使用合并结果管道，可以通过GitLab API将MR的标题和描述存入项目CI变量，再在main分支的push管道中读取这些变量：

步骤1：配置API令牌 #

创建一个具备项目变量编辑权限的GitLab个人访问令牌，添加为项目CI变量（命名为GITLAB_API_TOKEN，设置为保护和掩码）。

步骤2：添加MR变量更新任务 #

update_mr_metadata:
  stage: .pre
  rules:
    - if: >
        $CI_PIPELINE_SOURCE == "merge_request_event" &&
        $CI_MERGE_REQUEST_APPROVED &&
        $CI_MERGE_REQUEST_TITLE =~ /^v\d+(\.\d+){2}$/ &&
        $CI_MERGE_REQUEST_DESCRIPTION != "" &&
        $CI_MERGE_REQUEST_DESCRIPTION =~ $MERGE_REQUEST_DESC_PATTERN
  script:
    # 更新MR标题变量
    - |
      curl --request PUT --header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/variables/MR_TITLE" \
        --form "value=$CI_MERGE_REQUEST_TITLE" --form "protected=true"
    # 更新MR描述变量
    - |
      curl --request PUT --header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/variables/MR_DESCRIPTION" \
        --form "value=$CI_MERGE_REQUEST_DESCRIPTION" --form "protected=true"

步骤3：main分支的构建部署任务 #

build_and_deploy:
  stage: deploy
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
  script:
    - echo "使用MR标题作为镜像标签: $MR_TITLE"
    - echo "MR描述内容: $MR_DESCRIPTION"
    # 执行构建、部署逻辑

方案说明 #

• 该方案通过API将MR的元数据持久化到项目变量，让main分支的push管道可以读取
• 复杂度高于方案一，仅作为合并结果管道不可用时的备选方案

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