gitlab CI实践

1. 概念

每个工程里可编写.gitlab-ci.yml, 对应一个流水线（pipeline），流水线分不同阶段（stage），每个阶段包含不同作业（job）

每个作业有产物（artifacts）

默认情况下，后期阶段的作业会自动下载早期阶段作业创建的所有产物。可以使用 dependencies控制作业中的产物下载行为，只取部分产物。使用 needs 关键字时，作业只能从 needs 配置中定义的作业下载产物。

2. 多工程构建 - 产物依赖

多工程构建，如果一个工程依赖另外一个工程，比如usm-electron-client依赖usm-front生成的js、css、html等文件，

usm-electron-client的配置可以这样写：依赖usm/usm-front工程，build_usm_front这个作业，分支为$CI_COMMIT_BRANCH（当前usm-electron-client提交分支，这样写表示usm-front也需要有相应分支），分支得是分支名或者tag，不能是hash。

needs:
  - project: usm/usm-front
    job: build_usm_front
    ref: $CI_COMMIT_BRANCH
    artifacts: true

而usm_front的配置可这样写：

build_usm_front:
  image: openeuler/openeuler:20.03-lts—sp3-x86_64
  stage: build
  script:
    - yarn build
  tags:
    - x86_64, ssd
  artifacts:
    paths:
      - dist/
    expire_in: 5 day

trigger:
  stage: deploy
  variables:
    UPSTREAM_BRANCH: $CI_COMMIT_BRANCH
  trigger:
    project: usm/usm-electron-client
    branch: $CI_COMMIT_BRANCH
  when: manual

build_usm_front作业构建前端产物，trigger作业触发usm-electron-client工程，使用的分支为usm_front一样的提交分支。注意其实不用写触发，下游的项目同样可以从上游拿产物。只不过如果从上游工程构建，然后再构建下游工程，上游的产物一定会有。而如果直接从下游构建，可能存在上游项目的产物不存在的情况，比如上游分支不存在、没有构建、构建失败没有生产产物等。

实践中，我们的产物一般设置为多少天过期，下游来取的时候不一定能拿到，所以这种情况可以在工程勾选"Keep artifacts from most recent Successful jobs More information ”，这样即时设置了产物过期，也不会清理最新的产物，保证下游始终能取到。

或者更严谨一点，可以专门设置一个阶段，收到之前阶段的产物后，如果发现有生产tag，才上传产物，并且设置为永不过期。

注意：使用needs取其他工程是gitlab收费特性，要premium版本。同时较新的gitlab版本中，想取另外一个工程的产物，还需要去CI配置中设置哪些工程可以取本工程的产物。

3. 三方包管理

构建中往往要依赖其他三方组件、库、包等二进制文件，推荐使用minio（类似S3的对象存储）来管理，建立一个bucket，分门别类地存放这类文件，构建时下载使用。这类文件可以从互联网中下载，往往也没有包管理可以管理它们（比如C/C++的包）。当然现代语言的包还是推荐用包管理来做，比如nodejs、golang等。

4. 关于gitlab cache

在使用硬盘而非ssd的情况下，很多时候没有太大用处，瓶颈在于磁盘IO，特别是像前端/nodejs这样的有几万个小文件，而gitlab即使把缓存放在runner所在的机器作为一个zip（共享cache还是放在服务器上先下一次），unzip的速度依然很慢，实际缓存node_ modules测试下来，有很大的额外花销（overhead），甚至还不如自己把zip放在服务器上，下载下来解压缩

5. 变量

对于环境变量可使用 https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-gitlab-ciyml-file ，用variables关键字，而不是在作用中比如shell用export，cmd里用set来设置环境变量

6. 基于产物的构建

总的来说，像gitlab这样的系统构建还是基于任务的，而不是基于产物的

基于任务就是你告诉构建系统1做什么，2做什么，3做什么

而基于产物就是你告诉系统你的输入（依赖库、其他产物）是什么，你希望产物是什么

关于这个 可以去看 google software 中关于基于产物与基于任务的介绍

像这样基于任务的构建系统，缺点在于你构建时，你不确定你的依赖库变没有（尤其是大型工程），你只有老老实实的全量编译，造成改一点代码构建要很久

但其实我们可以把这个用在平时的非正式构建上

例如下面的例子 install_x86_64_debug这个作业，扩展了install_x86_64作业，它只依赖默认分支的tar_x86_64 与 generate_config_x86_64 这两个作业的产物，只要只两个产物是之前在默认分支构建过的，

就可以构建它

这样在平时的测试、调试中，我们只需专注 install_x86_64本身改动的逻辑，做到增量构建，不用每次都去构建上游tar_x86_64 与 generate_config_x86_64 这两个作业