使用Gitlab构建简单流水线CI/CD

什么是Gitlab

Gitlab实质上是一套DevOps工具

目前看起来，Gitlab属于是内嵌了一套CI/CD的框架，并且可以提供软件开发中的版本管理、项目管理等等其他功能。

这里需要辨别一下Gitlab和Github Gitee的区别。

GIthub大家都很熟悉了，一般大家都会去里面淘一些开源项目或工具代码，来快速实现一些功能。Gitee与之类似。我觉得属于是开源项目托管平台。

Gitlab不一样，他本质上是工具软件，虽然我注册的免费账号，也可以给每个库2G的存储空间，开源多人协作软件项目，但不是像Github那样的大市场。除了注册云服务账号，也可以在本地安装Gitlab的框架，或者在公司内网搭建Gitlab。 自己搭建一套Gitlab, 对企业而言，就非常诱人。

另外，值得一提的是，Gitlab自己内嵌了一套CI/CD工具。

我早就听说过CI/CD。但是干汽车电子和软件的大家都知道，面向嵌入式开发，特别是在Adaptive Platform 和SOC兴起之前，DevOps往往Dev都没实现自动化，根本Ops不起来。以前虽然接触过Jenkins的概念，但是没有深入研究。这次终于有机会接触Gitlab，就跳过Jekings这个老头直接来摆弄一下Gitlab的流水线。

GitLab Runner

Runner 是CI/CD中的打工人，也就是在CI/CD过程中每个Job的执行者。

在实现上，可以是云端共享的docker, 也可以是公司内搭建的服务器，甚至可以是自己PC上运行的虚拟机。

我这边就是在自己的虚拟机里安装了Runner。来实现自动编译。Runner在Linux系统中的表现为，下载一套Runner的程序并安装成为系统服务，,新建一个Linux账号供Runner使用，然后在CI/CD中的的git工程会load到Runner的文件系统中，然后执行配置文件中的指令。在安装Runner的过程中，会选择执行器，我选择的Shell. 那么应该就是调用了bash来执行传递给Runner的指令。

除了自己安装Runner来注册到项目给项目使用，像我注册的带云服务的账号，可以使用公用Runner。目前免费账户好像是一个月给免费400分钟编译，但是我编译了个Helloworld.cpp就用了差不多1分钟。可能真的用于开发还是需要自己搭建本地的Runner.

具体安装Runner的方式可以参照Gitlab工程网页中的指导或者官方文档。

.gitlab-ci.yml 文件

这个文件是CI的配置文件，在项目没有新建流水线的时候，可以从流水线设置那里进入，直接套用模板，新建一个配置文件， C++模板文件如下：

# This file is a template, and might need editing before it works on your project. # You can copy and paste this template into a new `.gitlab-ci.yml` file. # You should not add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword. # # To contribute improvements to CI/CD templates, please follow the Development guide at: # docs.gitlab /ee/development/cicd/templates.html # This specific template is located at: # gitlab /gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/C++.gitlab-ci.yml # use the official gcc image, based on debian # can use versions as well, like gcc:5.2 # see hub.docker /_/gcc/ image: gcc build: stage: build # instead of calling g++ directly you can also use some build toolkit like make # install the necessary build tools when needed # before_script: # - apt update && apt -y install make autoconf script: - g++ helloworld.cpp -o mybinary artifacts: paths: - mybinary # depending on your build setup it's most likely a good idea to cache outputs to reduce the build time # cache: # paths: # - "*.o" # run tests using the binary built before test: stage: test script: - ./runmytests.sh deploy: stage: deploy script: echo "Define your deployment script!" environment: production

上述文件有官方文档描述语法，这里简要记录一下解析：

image: gcc

表示启动这个Docker Runner，当然是里面包含GCC编译套件的。

如果是本地安装的Runner，不是使用Docker, 可以不需要这一句。

build: stage: build

表示定义一个job，名字叫build， 另外这个job处于stage build中。 stage会按照定义的先后顺序执行，在一个stage内部，如果没有needs这样的关键字来约束， job会并行执行。

script: - g++ helloworld.cpp -o mybinary

表示在这个job内会传递给Runner的指令脚本。 可以看出，前面我配置Runner的执行器为Shell，这里就直接传递shell指令就行了，就跟在本机Linux上一步一步编译一样。

artifacts: paths: - mybinary

这个是表示流水线产物，也就是可以在每一个job后下载的内容。 这里通过指定路径，可以把满足路径（正则匹配也可以）的内容收集上传附在流水线后，作为流水线产物。

我觉得这个产物可以附上编译的可执行文件或者运行测试生成的测试报告。

流水线触发

默认在每次git提交的时候，就会触发流水线执行。

也可以修改配置文件，让满足不同条件触发。

当然也可以手动触发执行。