Multi-project pipelines

• Multi-project pipeline visualization
• Creating multi-project pipelines from .gitlab-ci.yml
  • Specifying a downstream pipeline branch
  • Mirroring status from triggered pipeline
• Trigger a pipeline when an upstream project is rebuilt

Multi-project pipelines

版本历史

• 在 GitLab 7.14 中作为构建触发器引入 .
• 在 GitLab 12.8 中的所有层中用.

您可以跨多个项目设置GitLab CI / CD ，以便一个项目中的管道可以触发另一个项目中的管道.

GitLab CI / CD 是一个功能强大的持续集成工具，不仅适用于每个项目，而且适用于具有多项目管道的项目.

多项目管道对于需要跨项目相互依赖的较大产品很有用，例如采用 .

有关跨功能开发团队如何使用跨管道触发来为不同的微服务项目触发多个管道的演示，请参阅跨项目管道触发和可视化 .

此外，还可以可视化整个管道，包括所有跨项目的相互依存关系.

Let’s assume you deploy your web app from different projects in GitLab:

• 一个免费版本，它有自己的管道来构建和测试您的应用
• 一个用于付费版本的附加组件，还可以通过构建和测试
• 一个用于文档的文档，该文档还使用 SSG 进行构建，测试和部署

使用多项目管道，您可以可视化整个管道，包括三个项目的所有构建和测试阶段.

in GitLab Premium 9.3.

为项目配置 GitLab CI / CD 时，可以在上可视化作业的阶段.

在”合并请求”小组件中，将显示多项目管道微型图，并且当悬停或轻击（在触摸屏设备上）时，它们将展开并显示为彼此相邻.

• 在 9.3 中引入了CI_JOB_TOKEN在多项目管道中的使用.
• 在 GitLab 12.4 的所有层中都将CI_JOB_TOKEN用于多项目管道.

当您使用CI_JOB_TOKEN触发管道时 ，GitLab 会识别作业令牌的来源，因此在内部将这些管道在一起，从而可以在管道图上可视化它们的关系.

通过显示上游和下游管道依存关系的入站和出站连接，可以在管道图中显示这些关系.

版本历史

• 在GitLab Premium 11.8 中 .
• 在 12.8 中可用于所有层.

在 GitLab 11.8 之前，有必要实现一个管道作业，该作业负责发出 API 请求另一个项目中的管道 .

在 GitLab 11.8 中，GitLab 提供了新的 CI / CD 配置语法，使此任务更容易，并且避免需要 GitLab Runner 来触发跨项目管道. 下图说明了配置桥接作业：

在上面的示例中，一旦rspec作业在test阶段成功完成，则将启动staging桥作业. 该作业的初始状态将pending . manbetx 客户端打不开将在my/deployment项目中创建一个下游管道，并且，一旦创建管道， staging作业将成功. my/deployment是该项目的完整路径.

创建上游管道的用户需要具有对下游项目的访问权限（在本例中为my/deployment ）. 如果找不到下游项目，或者用户没有访问权限以在其中创建管道，则staging作业将被标记为failed .

警告：在该示例中，一旦创建了下游管道，该staging将被标记为成功. 如果要显示下游管道的状态，请参阅 .注意：对于常规作业，网桥作业不支持用户可以使用的每个配置条目. Runner 不会选择 Bridge 作业，因此添加对script支持毫无意义. 如果用户尝试使用不受支持的配置语法，则在创建管道时，YAML 验证将失败.

Specifying a downstream pipeline branch

可以指定下游管道将使用的分支名称：

rspec:
  stage: test
staging:
  stage: deploy
  trigger:
    project: my/deployment
    branch: stable-11-2

Use:

• project关键字，用于指定下游项目的完整路径.
• 该branch关键字指定由指定的项目分支的名称project . ，支持变量扩展.

在创建下游管道时，GitLab 将使用当前在分支的 HEAD 上的提交.

有时您可能想将变量传递到下游管道. 您可以使用variables关键字来执行此操作，就像定义常规作业时一样.

ENVIRONMENT变量将传递到下游管道中定义的每个作业. 当 GitLab Runner 选择工作时，它将作为环境变量使用.

  MY_VARIABLE: my-value
trigger-downstream:
  variables:
  trigger: my/project

您可能想使用例如预定义的变量传递有关上游管道的一些信息. 为此，您可以使用插值传递任何变量. 例如：

在这种情况下，具有与上游管道相关的值的UPSTREAM_BRANCH变量将传递到downstream-job作业，并在所有下游构建的上下文中可用.

提示：上游管道优先于下游管道. 如果在上游和下游项目中定义了两个具有相同名称的变量，则在上游项目中定义的变量将优先.

Mirroring status from triggered pipeline

版本历史

• 在 12.3 中引入 .
• 在 12.8 中 GitLab Core.

您可以使用strategy: depend将镜像状态从触发的管道镜像到源网桥作业. 例如：

trigger_job:
  trigger:
    project: my/project
    strategy: depend

您可以使用needs:pipeline关键字将管道状态从上游管道镜像到桥作业. 来自主服务器的最新管道状态将复制到桥接作业.

Example:

Limitations

由于网桥作业与常规作业略有不同，因此此处无法使用完全相同的配置语法，就像在定义要由跑步者选择的常规作业时通常使用的配置语法一样.

某些功能尚未实现. 例如，对环境的支持.

可用于网桥作业的是：

• trigger （定义下游管道触发器）
• stage
• allow_failure
• rules
• only and except
• when （仅适用于on_success ， on_failure和always值为）

in GitLab Premium 12.8.

You can trigger a pipeline in your project whenever a pipeline finishes for a new tag in a different project:

1. 转到项目的“设置”>” CI / CD”页面，然后展开” 管道订阅”部分.
2. 输入您要订阅的项目的路径.

现在，成功完成已订阅项目中新标签的任何管道都将在当前项目的默认分支上触发管道. 对于上游和下游项目，上游管道订阅的最大数量为 2.