Parent-child pipelines

Parent-child pipelines

在 GitLab 12.7 中 .

随着管道变得越来越复杂，一些相关的问题开始出现：

  • 分阶段的结构（其中一个阶段的所有步骤必须在下一阶段的第一个作业开始之前完成）会导致任意等待，从而使事情变慢.
  • 单个全局管道的配置变得非常漫长和复杂，使其难以管理.
  • 使用导入会增加配置的复杂性，并可能在无意间复制作业的情况下发生名称空间冲突.
  • 如此多的工作和阶段可以使流水线用户体验变得笨拙.

此外，有时管道的行为需要更动态. 选择启动（或不启动）子管道的功能是一项强大的功能，尤其是在动态生成 YAML 的情况下.

与多项目管道类似，管道可以触发一组同时运行的子管道，但是在同一项目中：

  • 该配置分为较小的子管道配置，这些子管道配置更易于理解. 这减少了理解整体配置的认知负担.
  • 导入在子管道级别进行，从而减少了发生冲突的可能性.
  • 每个管道只有相关的步骤，因此更容易理解正在发生的事情.

子管道可与其他 GitLab CI / CD 功能配合使用：

  • 仅在某些文件更改时才触发管道. 例如，这对于 monorepos 很有用.
  • 由于.gitlab-ci.yml的父管道和子管道都像普通管道一样运行，因此它们可以具有自己的行为和与触发器相关的顺序.

有关概述，请参见父子管道功能演示 .

最简单的情况是使用本地 YAML 文件定义管道配置来 . 在这种情况下，父管道将触发子管道，并继续运行而无需等待：

组成子管道时可以包含多个文件：

  1. microservice_a:
  2.   trigger:
  3.     include:
  4.       - local: path/to/microservice_a.yml

注意： trigger:include:可接受的最大条目数为三.

类似于多项目管道 ，我们可以在完成时将父管道设置为依赖于子管道的状​​态：

要将子管道触发为我们需要：

  • 将触发器作业设置为在合并请求上运行：
  1. # parent .gitlab-ci.yml
  2. microservice_a:
  3.     include: path/to/microservice_a.yml
  4.   rules:
  5.     - if: $CI_MERGE_REQUEST_ID

    • 设置子管道中的所有作业以在合并请求的上下文中进行评估：

    • Alternatively, setting the rule per job. For example, to create only in the context of merge request pipelines:

      1. # child path/to/microservice_a.yml
      2. job1:
      3.   script: ...
      4.   rules:
      5.     - if: $CI_MERGE_REQUEST_ID
      7. job2:

在 GitLab 12.9 中引入 .

您可以定义一个作业，该作业运行您自己的脚本来生成 YAML 文件，而不是从静态 YAML 文件运行子管道，然后将其 .

该技术在生成针对更改内容的流水线或构建目标和体系结构矩阵方面可能非常强大.

有关概述，请参阅使用动态生成的配置创建子管道 .

父管道可以触发许多子管道，但是子管道不能触发其他子管道. 请参阅以获取有关未来可能改进的讨论.