Gitlab推送代码触发双Pipeline问题排查及分支箭头含义咨询

一、推送代码触发双Pipeline的排查方向 #

• 首先检查项目根目录下的 .gitlab-ci.yml 配置，重点查看 workflow:rules、only/except、rules 字段，确认是否同时匹配了分支推送事件和合并请求事件两类触发条件，绝大多数双Pipeline场景都是因为推送的分支刚好关联了已打开的MR，两类规则同时命中，分别触发分支Pipeline和MR Pipeline。
• 进入项目「设置」→「CI/CD」→「流水线触发器」页面，检查是否配置了重复的推送触发规则，或者是否存在额外配置的Webhook在推送时重复调用Pipeline触发接口。
• 确认项目是否开启了「合并结果流水线」或「合并火车流水线」功能，若开启该功能，推送关联MR的分支时，会同时触发源分支的普通流水线和合并结果校验流水线，属于功能预期内的双触发场景。
• 检查本次推送是否同时携带了标签，若配置了标签触发规则，也会同时触发分支流水线和标签流水线。

二、分支活动箭头含义 #

• 右向箭头（→）：代表代码从当前分支向外流出，一般对应该分支有新提交推送到远端、或从该分支发起了指向其他分支的合并请求（MR）。
• 左向箭头（←）：代表有代码流入当前分支，一般对应有其他分支的提交待合入该分支、或存在从其他分支发起指向当前分支的待处理MR。

三、待处理MR与双Pipeline触发的关联 #

待处理MR是导致该现象的高频诱因。如果你的 .gitlab-ci.yml 没有做特殊规则过滤，GitLab默认会在推送已关联打开状态MR的源分支时，同时触发两个Pipeline：

1. 针对源分支本身提交的分支流水线
2. 针对该MR的合并请求流水线（用于校验代码合入目标分支后的运行状态）
   手动启动Pipeline时默认仅触发分支流水线，不会触发MR流水线，符合你观察到的现象。
   如果要避免双触发，可以修改 .gitlab-ci.yml 的 workflow:rules 配置，示例如下：

workflow:
  rules:
    # 优先匹配MR事件，触发MR流水线
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    # 匹配分支推送，排除已关联打开MR的分支，避免重复触发
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS == null
    # 匹配标签推送场景
    - if: $CI_COMMIT_TAG

相关截图 #

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