为什么 gitlab 在提交时运行重复的管道？

Question

我的工作内容如下.gitlab-ci.yml：

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"

当我将此更改提交到合并请求分支时，似乎正在启动两个管道。

这是 gitlab 中的已知问题吗？或者我在这里理解有问题？

Answer 1

GitLab 为您的分支和合并请求创建管道。这是 GitLab 的“预期” ^[1]功能，是使用rules:. （奇怪的是，当使用only/时except，合并请求管道仅在使用时才会发生only: - merge_requests）。

如果您只想禁用“合并请求管道”并仅运行分支管道，则可以包含默认分支管道模板，该模板提供了workflow:阻止合并请求管道的模板。

include:
  - template: 'Workflows/Branch-Pipelines.gitlab-ci.yml'

此外，您可以看到工作流的此答案，该工作流将仅在合并请求打开时防止合并请求管道和分支管道之间的重复。

[1]：我一直发现这是 GitLab 的一个怪癖，作为数百名用户的 GitLab 管理员，我已经多次收到这个问题。因此，您并不是唯一一个对这个“预期功能”感到惊讶的人

Answer 2

你没有做错任何事。这实际上是有意为之的，尽管这是合并请求有自己的管道上下文这一事实的一个奇怪的副作用。因此，当您提交到与合并请求关联的分支时，会启动两个管道：

1. 基于分支的管道，没有合并请求的上下文
2. 合并请求管道，填充了所有合并请求变量（这称为“分离”管道）

您可以通过workflow在管道中使用关键字来控制此行为。我们在存储库上使用以下工作流程设置：

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_TAG
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_COMMIT_REF_PROTECTED == "true"

上述规则将阻止分支管道运行，除非该分支是受保护分支（即，您正在合并到分支中main）、标记提交（即，您正在发布代码）或管道已被调度。这意味着当您提交到 MR 时，基于分支的管道（上述数字中的#1）不会运行，并且您只剩下一个正在运行的管道。