gitlab runner 的安装和.gitlab.yml文件配置及触发方式

1.背景

gitlab的CI执行会影响gitlab服务器的性能，而且项目有可能要在linux环境和Windows环境下分别运行和测试，因此，gitlab提供了gitlab runner机制，只需在目标主机上安装gitlab runner，就可以在该设备上进行项目的CI/CD工作。

2.前提

已经有gitlab服务器，并且其中有具体的项目，gitlab服务器如何的搭建，项目如何创建，请查阅相关文档。

3.目标

搭建gitlab runner，并配置.gitlab.yml文件，打通gitlab的CI环节。

4.实例

4.1搭建gitlab runner

本次实例的目标主机操作系统为centos7

[root@localhost ~]# cat /etc/redhat-release 
CentOS Linux release 7.8.2003 (Core)

本次实例gitlab runner的安装方式选用的yum方式，其他方式请参考相关文档

4.1.1添加yum源

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | bash

4.1.2yum安装

yum install gitlab-runner

这里我们发现最后安装的还是gitlab-ci-multi-runner，应该是为了兼容，和以前的名字进行了映射，均可以达到安装的目的。

4.1.3注册

[root@localhost yum.repos.d]# gitlab-ci-multi-runner register
Running in system-mode.                            
                                                   
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://192.168.1.120:8082/
Please enter the gitlab-ci token for this runner:
k1bymxs2_kJ2x3cwZyNe
Please enter the gitlab-ci description for this runner:
[localhost]: CQTrunner
Please enter the gitlab-ci tags for this runner (comma separated):
CQTrunner
Whether to run untagged builds [true/false]:
[false]: 
Whether to lock Runner to current project [true/false]:
[false]: 
Registering runner... succeeded                     runner=k1bymxs2
Please enter the executor: shell, ssh, docker, docker-ssh, docker+machine, docker-ssh+machine, kubernetes, parallels, virtualbox:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

这里的gitlab-ci token是如何得到的呢？
在gitlab服务器页面，选择具体项目的Settings->CD/CD，右侧Runners点击Expend展开

复制如下内容填入register头两项

Please enter the gitlab-ci tags for this runner (comma separated):
CQTrunner

在上述配置中，这项配置也很重要，这里的tags后续会在.gitlab-ci.yml文件配置中用到
配置好的runner可以到[root@localhost ~]# vi /etc/gitlab-runner/config.toml查看具体的配置信息并进行修改

4.1.4运行runner

[root@localhost codequalitytest]# gitlab-runner run
Starting multi-runner from /etc/gitlab-runner/config.toml ...  builds=0
Running in system-mode.                            
                                                   
Configuration loaded                                builds=0
Metrics server disabled                            

可以在上述gitlab服务器页面的场景中观察到该runner

4.2配置.gitlab.yml文件

.gitlab.yml文件用来控制CI过程中需要执行的操作，它的创建位置在工程的根目录下。直接创建即可。使用YAML语法，要用空格来缩进，不要使用Tab键。
Stages表示构建阶段，通常有build、test、deploy三个阶段，可以在一次Pipeline中设置多个Stages，Stages会按顺序执行，当一个Stage完成后，下一个Stage才会开始，当所有的Stage都执行成功后，Pipeline才算执行成功。
Jobs表示构建工作，表示某个Stage里面执行的工作，一个Stage中可以有多个Jobs，每个Job按顺序执行，任何Job失败都会导致Stage失败。Job中必须有Script部分。
当有新内容push到仓库，或者有代码合并时Gitlab会检查.gitlab.yml文件，如果文件存在，runner会根据文件内容进行本次commit的构建
举例

stages:
    - build

sonar:    #这就是一个job名
    stage: build       #这个job属于build这个stage
    tags:
        - CQTrunner       #这里引用到的就是上文gitlab runner register时配置的tags属性名
    script:                   #触发CI后执行的具体脚本
        - echo "building is done"
    only:               #触发条件，这里的配置只有当issue1分支push操作时会触发这个job
        - issue1      

4.3触发运行

如上我们在本地代码库的issue1分支，添加了.gitlab-ci.yml文件，add之后，commit，然后push到远端，就会触发sonar这个job，就会执行script脚本中的命令。观察效果，在gitlab服务器页面

想要看具体执行的信息，可以通过点击pass或者failed按钮进行查看，可见我们的echo语句生效了

这里经常会出现yaml文件格式不对的问题，可以借助gitlab页面CI Lint进行辅助编写

这样我们就跑通了每次push issue1分支都能触发CI Pipeline的例子，具体工作中我们可以调整分支名称，编写具体的script脚本或者丰富.gitlab-ci.yml其他配置信息来达到项目的具体要求。