不同 GitLab CI 合并请求规则之间的区别

Question

作为其他几位用户，我遇到了duplicate pipelines in GitLab CI/CD 的问题。虽然有一些关于如何防止这种分散在 GitLab 文档中的文档， 我的印象是各个文档页面和部分相当不一致。

我的问题是，以下规则有什么区别？或者，更具体地说，是否存在对这些规则进行不同评估的情况？

• Switch between branch pipelines and merge request pipelines 建议这样做来识别合并请求管道：

  if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  

• 此外，Switch between branch pipelines and merge request pipelines 也将此规则与$CI_COMMIT_BRANCH && 结合使用：

  if: '$CI_OPEN_MERGE_REQUESTS'
  

• 此外，MergeRequest-Pipelines.gitlab-ci.yml 使用第三条规则：

  if: $CI_MERGE_REQUEST_IID
  

非常感谢我可能忽略的文档页面的任何解释或提示。

Answer 1

为了避免重复创建管道以及您想要在分支管道和合并请求管道之间切换的要求，我建议使用这些workflow rules

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - if: '$CI_COMMIT_BRANCH' || '$CI_COMMIT_TAG'

还有另一个 SO-question 询问如何防止重复管道here

解释：

在下一节中，我将尝试解释您的不同规则以及 GitLab CI 在管道创建期间将如何评估它们。

merge_request_event-规则

使用这条规则：

if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

每次创建/更新合并请求时都会创建一个管道，但如果您没有其他预防机制（规则），也会为分支创建一个管道。 正如变量命名所指出的，这是关于管道触发器的来源，其他来源可能是schedule、push、trigger 等。

CI_OPEN_MERGE_REQUESTS 变量：

使用如下规则：

if: '$CI_OPEN_MERGE_REQUESTS'

如果此分支有开放的合并请求，GitLab 将创建新的管道。管道，因为将有一个合并请求管道（用 detached 标志表示）和一个分支管道用于您推送更改的分支。

if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'

当且仅当该分支上存在打开的 MR 时，上述规则将为您的分支创建管道。

if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
when: never

使用上述组合时，如果该分支上有打开的合并请求，则不会创建管道，这也可能是不可取的，因为 CI 应该为分支和/或合并请求运行测试。

但是如何能够为 MR 和 Branches 提供管道，同时防止管道创建中的重复？

- if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
  when: never
- if: '$CI_COMMIT_BRANCH' || '$CI_COMMIT_TAG'

使用上面设置的这条规则，GitLab 将为分支和合并请求（detached 的）创建管道，以及为 git-tags 创建管道，但它会阻止 GitLab 复制管道。 当有提交到分支或有 git-tag 时，最后一条规则评估为 true。

更多链接

• 官方docs 在 MR 和 Branch-Pipelines 之间切换
• 有关如何avoid 使用规则示例复制管道的文档