为什么向合并请求分支提交代码时GitLab会触发重复流水线？

这不是GitLab的已知问题，属于对CI触发规则的理解偏差，触发两条流水线是符合GitLab CI设计逻辑的正常行为。

双流水线触发逻辑 #

当你向已关联合并请求的分支提交代码时，GitLab默认会触发两类流水线：

• 推送事件触发的分支流水线，对应内置变量CI_PIPELINE_SOURCE值为push
• 合并请求更新事件触发的MR流水线，对应内置变量CI_PIPELINE_SOURCE值为merge_request_event

你当前配置的问题 #

你的配置没有对流水线或任务的触发场景做限制，导致两类流水线都满足运行条件：

• job1没有配置rules规则，默认会在所有类型的流水线中执行
• job2的规则逻辑是：匹配到推送事件时执行，其余所有场景也强制执行（无前置if的when: always会匹配所有剩余场景），因此job2在分支流水线和MR流水线中都可以运行

两类流水线都有可执行的任务，自然会同时启动两条流水线。

你可以通过全局workflow.rules限制整个流水线的触发场景，避免同时触发多条流水线，示例如下：

# 全局限制只允许推送事件触发流水线
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - when: never

stages:
  - stage1
  - stage2

job1:
  stage: stage1
  script:
    - echo "Running default stage1, pipeline_source=$CI_PIPELINE_SOURCE"

job2:
  stage: stage2
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - when: always
  script:
    - echo "Running STAGE2!   pipeline_source=$CI_PIPELINE_SOURCE"

如果你的业务需要MR流水线，就把上面的workflow.rules里的条件修改为匹配merge_request_event即可，也可以根据需求分别配置不同场景下的任务执行规则，注意不要随意添加无前置条件的when: always。

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