本文来自：

武让极狐(GitLab) 高级解决方案架构师

💡 极狐GitLab CI 依靠其一体化、轻量化、声明式、开箱即用的特性，在开发者群体中的使用率越来越高，在国内企业中仅次于 Jenkins ，排在第二位。

极狐GitLab 流水线有 4 种不同类型，分别是：

有向无环图流水线

父子流水线

多项目流水线

合并列车

但仅靠这些流水线类型名称和官方描述，我们很难理解其意义和用途。因此，作者结合众多用户反馈和自身实践，简明扼要 “重新定义” 了这些流水线类型，并通过 3 篇连载文章为您解答，帮助您掌握极狐GitLab 流水线。

第 1 篇分享了🔗有向无环图流水线。

本文是第 2 篇——父子流水线 + 多项目流水线，enjoy～

父子流水线 Parent-Child Pipelines

1. 官方定义

Parent-Child Pipelines 即父子流水线，它和 Multi-Project Pipelines 多项目流水线都属于下游流水线。所谓下游流水线：

由另一个流水线触发的任何极狐GitLab CI/CD 流水线。它可以是：

一个父子流水线，是与第一个流水线在同一个项目（代码库）中触发的下游流水线；

多项目流水线，是在与第一个流水线不同的项目（代码库）中触发的下游流水线。

父子流水线，官方定义和介绍如下：

父流水线是在同一项目（代码库）中触发下游流水线的流水线，下游流水线称为子流水线。

子流水线仍然根据阶段顺序执行他们的每个工作，但可以自由地继续他们的阶段，而无需等待父流水线中不相关的工作完成；

该配置被拆分为更小的子流水线配置。每个子流水线只包含更容易理解的相关步骤，减少了理解整体配置的认知负担；

导入在子流水线级别完成，减少了冲突的可能性。

这个解释比 DAG 流水线要容易理解一些，但是我们依然可以换一种比较接地气的方式进行重新描述。

2. 重新定义

父子流水线解决一个判断题+选择题。

主要功能：

（按条件触发并）执行同一个项目（代码库）中不同的流水线脚本。

3. 问题解答

接着第 1 篇有向无环图有向无环图流水线有向无环图中的问题 1 继续，还是那个跨平台项目。

问题 2

假如现在 iOS 平台应用有一些 Bug，开发人员仅对 iOS 部分代码进行了修改，然后希望编译打包 iOS 平台应用并发布上线。但不希望再次打包 PC 和 Android 平台，浪费时间和资源，怎么办？假如是个通用问题，在 3 个平台上都出现了，那么修改通用部分代码后还需要同时打包 3 个平台的应用，又该怎么办？这个跨平台项目文件目录如下：


- common
  - code_files...
  - .gitlab-ci.yaml #全部平台构建打包脚本
- android
  - code_files...
  - .gitlab-ci.yaml  #Android平台构建打包脚本
- ios
  - code_files...
  - .gitlab-ci.yaml #iOS平台构建打包脚本
- pc
  - code_files...
  - .gitlab-ci.yaml #pc平台构建打包脚本

为了解决这个问题，就需要使用到父子流水线，主要会使用到 rules:is:changes 和 trigger 关键字，用来实现按条件触发，然后执行不同流水线脚本，比如：

stages:
  - build
  - triggers

android_trigger:
  stage: triggers
  # 当android目录下的文件发生变化时触发
  rules:
    - if: 
      changes:
        - android/*
  # 触发执行android/.gitlab-ci.yml脚本
  trigger:
    include: android/.gitlab-ci.yml
    strategy: depend
  

ios_trigger:
  stage: triggers
  # 当ios目录下的文件发生变化时触发
  rules:
    - if: 
      changes:
        - ios/*
  # 触发执行ios/.gitlab-ci.yml脚本
  trigger:
    include: ios/.gitlab-ci.yml
    strategy: depend
  

pc_trigger:
  stage: triggers
  # 当pc目录下的文件发生变化时触发
  rules:
    - if:
      changes:
        - pc/*
  # 触发执行pc/.gitlab-ci.yml脚本
  trigger:
    include: pc/.gitlab-ci.yml
    strategy: depend

common_build:
  stage: build
  script:
      - echo "common build"
  # 当common目录下的文件发生变化时触发，执行默认的根目录.gitlab-ci.yml脚本
  rules:
    - changes:
      - common/*

当修改 iOS 目录文件后，只触发了 ios/.gitlab-ci.yml 脚本的执行。

当修改 common 目录文件或直接手动执行流水线后，触发执行根目录的 .gitlab-ci.yml 脚本，也就是触发所有构建。

当然这个判断题不是必要的，可以在一个正常的 Job 中直接做选择题，比如：


microservice_a:
  trigger:
    include: path/to/microservice_a.yml

也可以修改判断题的条件，比如使用极狐GitLab 的变量来进行条件控制：

pc_trigger:
  stage: triggers
  # 当PLATFORM变量的值为PC时触发
  rules:
    - if: $PLATFORM == "PC"
  # 触发执行pc/.gitlab-ci.yml脚本
  trigger:
    include: pc/.gitlab-ci.yml
    strategy: depend

这样就实现了按照条件触发不同的流水线脚本，这也就是说为什么父子流水线是解决一个判断题 + 选择题，以及它是如何（按条件触发并）执行同一个项目中不同的流水线脚本的。

4. 总结父子流水线使用场景

1. 按条件灵活触发并执行一个项目中不同的流水线脚本：比如在一个项目中，将一个复杂的流水线脚本拆分成多个简单的流水线脚本，通过 tigger 关键字组合，实现解耦和降低复杂度。或类似上文中提到的按条件单独执行 Monorepo 中部分模块的构建、测试、打包。

2. 父子流水线 + DAG 流水线：可以将父子流水线与 DAG 流水线结合使用，比如 pc/.gitlab-ci.yml 中依然使用 DAG 流水线使得 test_pc 依赖 build_pc 和 build_pc_dll。

多项目流水线 Multi-Project Pipelines

1. 官方定义

Multi-Project Pipelines 多项目流水线，它和父子流水线都属于下游流水线，官方定义和介绍如下：

可以跨多个项目（代码库）设置极狐GitLab CI/CD，以便一个项目（代码库）中的流水线可以触发另一个项目（代码库）中的流水线。您可以在一个地方可视化整个流水线，包括所有跨项目的相互依赖关系。

熟悉了父子流水线后，再看多项目流水线就比较简单了。它们都是触发下游不同的流水线，只是面向的对象不同，父子流水线面向的是同一个项目（代码库），而多项目流水线是面向不同的项目（代码库），这也决定了它们使用的场景不同。

2. 重新定义

继续用通俗的语言来解释：

多项目流水线解决的是排列组合题。

主要功能：

编排并执行不同的项目（代码库）中的流水线脚本。

回顾上文中的 DAG 流水线和父子流水线，使用的场景大多都是在 Monorepo 模式下，对一个项目内的流水线或者 Job 进行编排。而现在架构设计领域的主流思想还是模块化和微服务，所以不少企业或开发人员还是习惯对项目进行拆分，用多个代码库进行管理。在这样的模式下，DAG 和父子流水线使用的机会就相对较少了，而多项目流水线就派上了用场。举例如下：

3. 问题解答

问题 3

假设有个 Web 项目，在极狐GitLab 中建立了一个群组 MyProject 来管理这个项目。前端代码放在代码库 MyProject/Frontend 中，后台代码放在代码库 MyProject/Server 中。测试团队对前端代码编写的UI自动化测试脚本放在代码库 MyProject/Frontend-UI-Testing 中，对后台代码编写的 API 自动化测试脚本放在代码库 MyProject/Server-API-Testing 中。要求部署时先部署后台代码，再部署前端代码，并同步进行后台的 API 测试，最后再进行前端的 UI 测试。

使用多项目流水线来解决这个问题，依然要使用 trigger 关键字。由于该问题中，后台代码的流水线是整个业务链条的起点，所以先看代码库 MyProject/Server 的流水线：

stages:          
  - build
  - test
  - deploy
  - downstream
# 编译构建
build-job:      
  stage: build
  script:
    - echo "Compiling code..."
    - echo "Compile complete."
# 单元测试
unit-test-job:   
  stage: test    
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 6
    - echo "Code coverage is 90%"
# 格式校验
lint-test-job:   
  stage: test    
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 1
    - echo "No lint issues found."
# 部署任务
deploy-job:      
  stage: deploy  
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."
# API测试
api-test-job:
  stage: downstream
  # 触发下游流水线
  trigger:
    project: MyProject/Server-API-Testing
    strategy: depend
# 部署前端
deploy-frontend-job:
  stage: downstream
  # 触发下游流水线
  trigger:
    project: MyProject/Frontend
    strategy: depend

当前端项目部署成功后需要执行前端的 UI 测试，所以代码库 MyProject/Frontend 的流水线如下：


stages:          
  - build
  - test
  - deploy
  - downstream
  
# 省略build、test、deploy脚本  

# UI测试
ui-test-job:
  stage: downstream
  # 触发下游流水线
  trigger:
    project: MyProject/Frontend-UI-Testing
    strategy: depend

流水线运行效果如下，也就是官方定义中所说的 “您可以在一个地方可视化整个流水线，包括所有跨项目的相互依赖关系”，但这个功能是属于极狐GitLab 专业版及以上版本，免费版无法看到这个效果。