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
其他配置信息来达到项目的具体要求。