Pipelines for Merged Results

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

Pipelines for Merged Results

Introduced in GitLab Premium 11.10.

提交合并请求时，您正在请求将更改从源分支合并到目标分支. 默认情况下，CI 管道针对源分支运行作业.

使用用于合并结果的管道，管道可以像源分支中的更改已被合并到目标分支中一样运行.

如果管道由于目标分支中的问题而失败，则可以等到目标修复后再重新运行管道. 这个新管道将像源与已更新的目标合并一样运行，并且您无需重新设置基准.

目标分支更改时，管道不会自动运行. 仅对源分支的更改会触发新的管道. 如果自上一个成功的管道以来已经过去了很长时间，则您可能需要在合并之前重新运行它，以确保源更改仍然可以成功合并到目标中.

当合并请求无法合并时，管道仅针对源分支运行. 例如，当：

在这些情况下，管道将作为合并请求的管道运行，并标记为detached . 如果这些情况不再存在，则新管道将再次针对合并结果运行.

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

Prerequisites

要启用管道以合并结果：

Enable pipelines for merged results

要为项目的合并结果启用管道：

  1. 配置您的 CI / CD 配置文件，以便为合并请求运行管道或单个作业.
  2. 访问项目的设置>常规，然后展开合并请求 .
  3. Check 为合并结果启用合并训练和管道.
  4. Click 保存更改.

警告：如果选中该复选框，但未将 CI / CD 配置为使用管道处理合并请求，则合并请求可能会停留在未解决的状态，或者管道可能会被丢弃.

Using Merge Trains

为合并结果启用管道时 ，GitLab 会自动显示” 开始/添加合并训练”按钮 .

通常，这是比立即合并合并请求更安全的选择，因为在实际合并发生之前，将使用预期的合并后结果评估合并请求.

有关更多信息，请阅读合并火车上的文档 .

Automatic pipeline cancellation

Introduced in GitLab Premium 12.3.

GitLab CI / CD 可以检测到冗余管道的存在，并会自动取消它们以节省 CI 资源.

当用户在进行中的合并列车中立即合并请求时，将重新构建该列车，因为它将重新创建预期的合并后提交和管道. 在这种情况下，合并序列可能已经具有针对先前预期的合并后提交运行的管道. 这些管道被认为是多余的，将被自动取消.

Troubleshooting

Pipelines for merged results not created even with new change pushed to merge request

可能是由于某些禁用的功能标志引起的. 请确保在您的 GitLab 实例上启用了以下功能标志：

  • :merge_ref_auto_sync

要检查和设置这些功能标志值，请要求管理员：

  1. 登录到 GitLab 实例的 Rails 控制台：

    1. sudo gitlab-rails console

  2. 检查标志是否启用：

    1. Feature.enabled?(:merge_ref_auto_sync)

  3. 如果需要，启用功能标志：

    1. Feature.enable(:merge_ref_auto_sync)

Intermittently pipelines fail by fatal: reference is not a tree: error

由于用于合并结果的管道是在合并请求（ refs/merge-requests/<iid>/merge ）的合并 ref 上运行的，因此 Git 引用可能会在意外的时间被覆盖. 例如，当源分支或目标分支是高级时. 在这种情况下，流水线由于fatal: reference is not a tree:错误而失败，这表明在合并引用中未找到 checkout-SHA.

在 GitLab 12.4 上，通过引入Persistent pipe refs改进了此行为. 您应该能够在任何时候创建管道，而不必考虑错误.