Pipelines for Merge Requests

原文：https://docs.gitlab.com/ee/ci/merge_request_pipelines/

• Prerequisites
• Configuring pipelines for merge requests
  • Use rules to run pipelines for merge requests
  • Use only or except to run pipelines for merge requests
    • Excluding certain jobs
    • Excluding certain branches
• Pipelines for Merged Results
  • Merge Trains
• Important notes about merge requests from forked projects
• Additional predefined variables
• Troubleshooting
  • Two pipelines created when pushing to a merge request
  • Two pipelines created when pushing an invalid CI configuration file

Pipelines for Merge Requests

在 GitLab 11.6 中引入 .

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

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

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

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

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

Prerequisites

要为合并请求启用管道：

• 您的存储库必须是 GitLab 存储库，而不是外部存储库 .
• 在 GitLab 11.10 和更高版本中 ，您必须使用 GitLab Runner 11.9.

Configuring pipelines for merge requests

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

Use rules to run pipelines for merge requests

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

Use only or except to run pipelines for merge requests

If you want to continue using only/except, this is possible but please review the drawbacks below.

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

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

build:
  stage: build
  script: ./build
  only:
    - master
test:
  stage: test
  script: ./test
  only:
    - merge_requests
deploy:
  stage: deploy
  script: ./deploy
  only:
    - master

Excluding certain jobs

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

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

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

• 所有管道始终运行A和B
• C仅针对合并请求运行.

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

.only-default: &only-default
  only:
    - master
    - merge_requests
    - tags
A:
  <<: *only-default
  script:
    - ...
B:
  <<: *only-default
  script:
    - ...
C:
  script:
    - ...
  only:
    - merge_requests

Therefore:

• 由于A和B在所有情况下都具有only:执行规则，因此它们将始终运行.
• 由于C指定仅针对合并请求运行，因此它将不会针对除合并请求管道之外的任何管道运行.

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

Excluding certain branches

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

# Does not exclude a branch named "docs-my-fix"!
test:
  only: [merge_requests]
  except: [/^docs-/]

相反，可以将$CI_COMMIT_REF_NAME预定义环境变量与only:variables结合使用以完成此行为：

test:
  only: [merge_requests]
  except:
    variables:
      - $CI_COMMIT_REF_NAME =~ /^docs-/

Pipelines for Merged Results

阅读有关合并结果的管道的文档 .

Merge Trains

阅读有关合并火车的文档 .

Important notes about merge requests from forked projects

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

1. 分叉一个父项目.
2. 从分支项目中创建一个以父项目中的master分支为目标的合并请求.
3. 管道在合并请求上运行.
4. 父项目的维护者检查管道结果，如果最新的管道通过，则合并到目标分支.

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

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

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

Additional predefined variables

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

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

Troubleshooting

Two pipelines created when pushing to a merge request

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

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

Two pipelines created when pushing an invalid CI configuration file

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

在极少数情况下，会创建重复的管道.

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