Pipelines for Merge Requests

在 GitLab 11.6 中 .

在基本配置中，每次更改被推送到分支时，GitLab 都会运行管道.

如果希望管道仅在创建或更新合并请求时运行作业，则可以将管道用于合并请求 .

在用户界面中，这些管道被标记为detached . 否则，这些管道看起来与其他管道相同.

具有开发者任何用户都可以为合并请求运行管道.

Note: If you use this feature with , pipelines for merge requests take precedence over the other regular pipelines.

要为合并请求启用管道：

Configuring pipelines for merge requests

要为合并请求配置管道，您需要配置 . 有几种不同的方法可以做到这一点：

当使用rules ，这是首选方法，我们建议从workflow:rules模板开始，以确保基本配置正确. 该链接提供了有关如何执行此操作以及如何进行自定义的说明.

使用此方法时，只需指定only: - merge_requests每个作业的only: - merge_requests . 在此示例中，管道包含配置为在合并请求上运行的test作业.

和deploy作业没有only: - merge_requests参数，因此它们将不会在合并请求上运行.

only: [merge_requests]参数的行为是，只有具有该参数的作业才在合并请求的上下文中运行；没有其他作业将运行.

但是，您可以反转此行为，并运行除一两个之外的所有作业.

考虑下面的管道，作业A ， B和C 假设您要：

为此，可以如下配置.gitlab-ci.yml文件：

Therefore:

这可以帮助您避免为所有作业添加only:规则，以使其始终运行. 您可以使用这种格式来设置评论应用，以帮助节省资源.

使用/ except时，合并请求的管道需要特殊处理. 与普通的分支引用（例如refs/heads/my-feature-branch ）不同，合并请求引用使用特殊的 Git 引用，看起来像refs/merge-requests/:iid/head . 因此，以下配置将无法正常工作：

相反，可以将与only:variables结合使用以完成此行为：

阅读的文档 .

请注意，当前行为可能会更改. 在通常的贡献流程中，外部贡献者遵循以下步骤：

当前，这些管道是在派生项目中创建的，而不是在父项目中创建的. 这意味着您不能完全信任管道结果，因为从技术上讲，外部贡献者可以通过在派生项目中调整其 GitLab Runner 来掩盖其管道结果.

GitLab 不允许在父项目中创建这些管道有多种原因，但是最大的原因之一是安全性问题. 外部用户可以通过修改.gitlab-ci.yml （可能是某种凭据）从父项目中窃取秘密变量. 这不应该发生.

我们正在讨论一种安全的解决方案，该解决方案针对从分支项目提交的合并请求运行管道，请参阅有关权限扩展的问题 .

通过将管道用于合并请求，GitLab 将其他预定义变量公开给管道作业. 这些变量包含关联的合并请求的信息，因此将您的作业与集成非常有用.

您可以在参考表中找到可用变量的列表. 变量名称以CI_MERGE_REQUEST_前缀开头.

如果使用rules时遇到重复的管道，请查看rules和only / except之间的，这将帮助您正确设置起始配置.

如果您在使用only/except时看到两个管道，请参见上述与only/except一起使用的注意事项（或者，考虑使用rules ）.

推送到具有无效 CI 配置文件的分支会触发两种类型的失败管道的创建. 一个管道是失败的合并请求管道，另一个管道是失败的分支管道，但两者都是由相同的无效配置引起的.

有关详细信息，请参见此问题 .