GitLab CI/CD合并请求触发清理作业的实现方案咨询

你之前用$CI_MERGE_REQUEST_STATE的思路走不通，原因有两个：一是这个变量根本不是GitLab内置变量；二是MR流水线（即CI_PIPELINE_SOURCE == "merge_request_event"的流水线）只会在MR打开、更新时运行，合并后MR状态变为merged，但此时不会再触发MR流水线，而是触发目标分支的push流水线。

下面给你两种靠谱的实现方式：

方式一：在目标分支的push流水线中触发清理 #

当MR合并到目标分支（比如main）时，GitLab会自动触发目标分支的push流水线。我们可以在清理作业里判断当前提交是合并提交，再提取对应的MR编号来清理环境。

示例CI配置：

stages:
  - install
  - test
  - package
  - deploy
  - cleanup

# 省略install、test、package、deploy的作业配置
# 注意：deploy作业要给每个MR创建专属环境，比如命名为dev-$CI_MERGE_REQUEST_IID

cleanup:
  stage: cleanup
  script:
    # 从合并提交标题里提取MR编号（GitLab合并提交标题格式是「Merge !XXX into 分支名」）
    - MR_IID=$(echo "$CI_COMMIT_TITLE" | grep -o '![0-9]*' | tr -d '!')
    - echo "开始清理MR #$MR_IID对应的开发环境"
    # 这里写你的实际清理命令，比如删除容器、删除部署资源等
    # 例如：kubectl delete namespace dev-$MR_IID
  rules:
    # 只在目标分支的push流水线中触发，且是合并提交
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"'
      - if: '$CI_COMMIT_MESSAGE =~ /Merge branch/ || $CI_COMMIT_MESSAGE =~ /Merge !/'

方式二：利用GitLab环境生命周期自动清理（推荐） #

如果你的deploy作业是给每个MR创建专属环境（比如dev-$CI_MERGE_REQUEST_IID），可以直接通过GitLab的环境配置，让MR合并后自动触发清理作业。

示例CI配置：

stages:
  - install
  - test
  - package
  - deploy
  - cleanup

deploy:
  stage: deploy
  script:
    # 部署到专属的MR开发环境
    - echo "部署到环境 dev-$CI_MERGE_REQUEST_IID"
    # 你的部署命令...
  environment:
    name: dev-$CI_MERGE_REQUEST_IID
    url: https://dev-$CI_MERGE_REQUEST_IID.your-domain.com
    # 指定停止当前环境时要触发的作业
    on_stop: cleanup
  rules:
    # 只在MR流水线中运行部署
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

cleanup:
  stage: cleanup
  script:
    # 清理当前环境对应的资源
    - echo "清理环境 $CI_ENVIRONMENT_NAME"
    # 你的清理命令...
  environment:
    name: dev-$CI_MERGE_REQUEST_IID
    # 标记此作业为停止环境的操作
    action: stop
  rules:
    # 当MR合并后，GitLab会自动触发这个作业
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_EVENT_TYPE == "merged_result"'

这种方式的好处是不需要自己提取MR编号，GitLab会自动关联对应的环境，只要MR合并，就会触发cleanup作业停止并清理环境。

内容的提问来源于stack exchange，提问作者Mowgli Is Famous