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: manualbuild_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 这两个作业
