概念

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