3. 跨项目流水线概述：父子流水线、多项目流水线、触发方式对比

在微服务与多仓库架构中，单一 .gitlab-ci.yml 已无法满足复杂交付场景。GitLab 提供了两种跨项目流水线编排机制——父子流水线（Parent-Child Pipeline）与多项目流水线（Multi-Project Pipeline），分别解决“同一仓库内职责拆分”与“跨仓库协同触发”的问题。本章从概念、适用场景、触发方式三个维度进行系统对比。

3.1 父子流水线（Parent-Child Pipeline）

父子流水线允许在同一个项目仓库内，由父流水线动态生成多个子流水线。子流水线继承父流水线的上下文（如变量、制品），但拥有独立的阶段执行空间。

3.1.1 典型结构

• 父流水线：负责触发条件判断、参数组装、调用子流水线。
• 子流水线：各自定义独立的 .gitlab-ci.yml（通常存放在子目录中），专注单一职责（如编译、测试、安全扫描）。
• 触发方式：使用 trigger 关键字，指向子流水线的 YAML 文件路径。

# 父流水线 .gitlab-ci.yml
stages:
  - triggers

build-service-a:
  stage: triggers
  trigger:
    include: services/service-a/.gitlab-ci.yml
    strategy: depend
  variables:
    SERVICE_NAME: "service-a"

build-service-b:
  stage: triggers
  trigger:
    include: services/service-b/.gitlab-ci.yml
    strategy: depend
  variables:
    SERVICE_NAME: "service-b"

3.1.2 适用场景

3.2 多项目流水线（Multi-Project Pipeline）

多项目流水线用于跨不同 GitLab 项目的流水线联动。上游项目完成后，自动触发下游项目的流水线，形成跨仓库的交付链。

3.2.1 典型结构

• 上游项目：在 job 中使用 trigger 关键字，指定下游项目的完整路径（如 group/project）。
• 下游项目：被触发后独立运行自己的 .gitlab-ci.yml，不共享上游的制品（除非通过 API 或 artifacts 传递）。
• 触发方式：支持跨组、跨命名空间触发，需配置 CI/CD 或使用项目访问令牌。

# 上游项目 .gitlab-ci.yml
stages:
  - trigger-downstream

deploy-to-staging:
  stage: trigger-downstream
  trigger:
    project: my-group/my-downstream-project
    branch: main
    strategy: depend
  variables:
    DEPLOY_TAG: "$CI_COMMIT_TAG"

3.2.2 适用场景

3.3 触发方式对比

两种流水线模式在触发机制、变量传递、制品共享、权限控制等方面存在显著差异。下表从 8 个关键维度进行对比：

3.4 触发策略选择指南

3.4.1 选择决策树

1. 是否在同一仓库？
   • 是 → 使用父子流水线
   • 否 → 使用多项目流水线
2. 是否需要动态生成子流水线？
   • 是 → 父子流水线（支持 rules 动态 include）
   • 否 → 两种均可，按仓库边界选择
3. 是否需要跨团队权限隔离？
   • 是 → 多项目流水线（每个项目独立权限）
   • 否 → 父子流水线（权限统一管理）

3.4.2 混合使用模式

在实际生产环境中，两种模式可以组合使用：

# 父流水线同时触发子流水线和跨项目流水线
stages:
  - child
  - cross-project

trigger-child:
  stage: child
  trigger:
    include: modules/module-a/.gitlab-ci.yml

trigger-downstream:
  stage: cross-project
  trigger:
    project: ops/deploy-platform
    branch: main