概念
Gitlab上的CI基于事后模式，也就是说在代码合入主干之后，进行编译、测试。在这点上，和gerrit的模式完全不同。
实现
Gitlab自己已经集成CI、Issue管理等功能了，所以不需要额外安装其他服务。
Gitlab上的job配置，是以文件方式保存在项目的根目录下面，文件名是.gitlab-ci.yml
runner就是执行编译或者测试的目标机器，runner分两种：
-
Shared runners：gilab上所有项目都可以用 -
Specific runners：按照项目配置，只用在一个特定的项目上。
步骤
- 创建一个代码库
- 编写测试相关的文件
- 编写文件
.gitlab-ci.yml
下面是一个简单的例子：
- 编写文件
job1:
tags:
- linsee
script: "./execute-script-for-job1"
这个测试任务名字是job1，在标签为linsee的机器上执行，执行时使用的脚本是：项目根目录下，名字为execute-script-for-job1的脚本文件
- 在根目录下创建
execute-script-for-job1脚本文件
g++ main.cpp
我们只做简单的编译测试
上传这两个文件，并且包括测试文件
main.cpp-
配置
Specific Runners- 在你的目标机器上，下载文件
wget https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-linux-amd64
- 配置
执行
./gitlab-ci-multi-runner-linux-amd64 register
按提示输入相应信息（可以在右上角配置 -> Runner里面获取）
...
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
https://这里是你的gitlab的url/ci
Please enter the gitlab-ci token for this runner:
在这里输入你的token
Please enter the gitlab-ci description for this runner:
[xxxxx]:
Please enter the gitlab-ci tags for this runner (comma separated):
linsee
- 运行
./gitlab-ci-multi-runner-linux-amd64 run
这时候，在右上角配置 -> Runner -> Specific runners下面就可以看到你刚注册上来的机器了。
上面有name和tag，如下：
Paste_Image.png
- 修改main.cpp，并推送到gitlab上，就会自动触发CI了。
CI的执行结果，可以在Pipelines里面看到，当然在这里你也可以重新触发（执行不稳定，或者调试环境时用）
Paste_Image.png
