不同 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 问题询问如何防止重复管道 here

解释：

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

merge_request_event-规则

使用这条规则：

if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

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

CI_OPEN_MERGE_REQUESTS变量：

使用如下规则：

if: '$CI_OPEN_MERGE_REQUESTS'

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

if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'

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

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

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

但是如何能够拥有 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.

时，最后一条规则的计算结果为真

更多链接

• 官方docs 关于在 MR 和分支流水线之间切换
• 关于如何 avoid 使用规则示例复制管道的文档