GitLab CI/CD 多项目，多流水线制品合并方案

前言

在做CI/CD流水线时，有时会遇到非常复杂的项目架构，比如一个前后端分离的项目，在前端构建完成后，需要将前端的制品存放到后端项目的指定目录，以此来构建一个单体镜像，包含了前后端。有些情况是前后端在同一个仓库，而大多数情况是，前端和后端分别在二个不太的git仓库。这个时候就需要 跨项目，跨流水线的制品合并需求。
如果你是GitLab 的付费玩家，可以直接使用 needs:project 详情可以查阅 在极狐GitLab CI/CD流水线中使用制品依赖
。但如果是免费（白嫖）社区玩家，又需要一个制品合并的方案，可以试试下面这种方案。

跨项目，跨流水线制品合并方案

首先需要在linux服务器上安装 GitLab Runner， 注意在安装后，GitLab Runner 是以 gitlab-runner用户来运行的，如果遇到没有权限，或找到指令时，试一下修改权限，或切换用户。

然后注册一个shell作为执行器的runner

该runner将应用于需要构建的项目

如果你喜欢使用Docker 来运行GitLab Runner，同样也是可以的。但在注册Runner时，需要为项目挂载一个宿主机的目录。该目录就是用于同步容器内的制品。

流水线示范

主流水线

stages:
  - ready
  - build
  - create

default:
  tags:
    - shell  

ready_job:
  stage: ready
  script:
    - echo '基座准备工作'
  only:
    - master

build_self_job:
  stage: build
  script:
    - echo '开始构建多个应用，生成制品'
    - ls -l
    - cp -rf public/. /home/gitlab-runner/cicd-group/base
    - cd /home/gitlab-runner/cicd-group/base
    - ls -l 
  artifacts:
    paths:
    - public
  only:
    - master

build_other_job:
  stage: build
  trigger: 
    project: c860/sub-app
    branch: master
    strategy: depend
    
creat_app:
  stage: create
  script:
    - cd /home/gitlab-runner/cicd-group/sub-app
    - ls -l

子项目流水线

default:
  tags:
    - shell    
build_job:
  stage: deploy
  script:
    - echo '开始构建子应用'
    - ls -l
    - cp -rf public/. /home/gitlab-runner/cicd-group/sub-app
    - cd /home/gitlab-runner/cicd-group/sub-app
    - ls -l     
  artifacts:
    paths:
      - public
  only:
    - master

这里有二个流水线， 主流水线和子流水线，我们需要将主流水线的制品public目录，拷贝到宿主的/home/gitlab-runner/cicd-group/base目录中。

然后触发子流水线，

在子流水线中，
我们将项目根目录下的public 拷贝到 宿主的 /home/gitlab-runner/cicd-group/sub-app 目录下。

做完以上的，流水线接着会运行主流水线的creat_app 作业。 在这个作业里，你可以从/home/gitlab-runner/cicd-group目录中拿到所有的制品文件。

运行效果图

strategy: depend 该配置是关键，没有该配置只会创建子流水线，并不会等子流水线完成后，再执行主流水线后续作业。

有关多项目流水线的资料 以及 trigger 关键词的资料

https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html

https://docs.gitlab.com/ee/ci/yaml/index.html#trigger

升级版本

stages:
  - ready
  - build
  - create

.release_config:
  tags:
    - shell  
  only:
    - tags
    - master
  cache:
    key: $CI_PROJECT_NAME
    paths:
      - node_modules

ready_job:
  extends: .release_config
  stage: ready
  script:
    # 清空用于存放制品的目录
    - rm -rf /home/gitlab-runner/cicd-group
    - mkdir -p /home/gitlab-runner/cicd-group

build_self_job:
  extends: .release_config
  stage: build
  script:    
    - cp -rf public/* /home/gitlab-runner/cicd-group  

build_other_job:
  stage: build
  variables:
      UPSTREAM_BUILD_TAG: $CI_COMMIT_TAG
  trigger:
    project: c860/sub-app
    branch: $CI_COMMIT_TAG
    strategy: depend
    
creat_app:
  extends: .release_config
  stage: create
  script:
    - cp -rf Dockerfile nginx-config.conf /home/gitlab-runner/cicd-group
    - cd /home/gitlab-runner/cicd-group
    - docker build -t 0901:$CI_COMMIT_TAG .
    # - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL
    # - docker push $APP_IMAGE_PRO_NAME # 推送镜像
    # - docker rmi $APP_IMAGE_PRO_NAME # 删除本地镜像
  # artifacts:
  #   paths:
  #   - cicd-group

关于trigger的官方解释： https://docs.gitlab.com/ee/ci/yaml/#linking-pipelines-with-triggerstrategy

英文原文

By default, the trigger job completes with the success status as soon as the downstream pipeline is created.

To force the trigger job to wait for the downstream (multi-project or child) pipeline to complete, use strategy: depend. This setting makes the trigger job wait with a “running” status until the triggered pipeline completes. At that point, the trigger job completes and displays the same status as the downstream job.

This setting can help keep your pipeline execution linear. In the following example, jobs from subsequent stages wait for the triggered pipeline to successfully complete before starting, which reduces parallelization