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改进了此行为. 您应该能够在任何时候创建管道,而不必考虑错误.