基本概念
CI/CD
CI全称为Continuous Integration
代表持续集成的意思,通俗来说就是持续的自动构建(单元测试、打包等)。
CD全称为Continuous Deployment
代表持续交付的意思,在代码构建完成后自动部署上线。
gitlab-ci/cd
配置方法
1.ci文件配置
gitlab-ci
是gitlab
自带的功能,只需在项目的根目录添加一个.gitlab-ci.yml
的文件名即可。例如我所使用的这个:
1 | stages: |
stages
为具体步骤,名称均为自定义。only
代表只对dev
分支进行ci/cd
操作,其余分支不触发script
代表具体执行的脚本
在有了这个文件之后,gitlab
便会去寻找与之绑定的gitlab-runner
(即具体执行script
的所在服务器)。
安装runner
这里我是用的是docker
来运行gitlab-runner
,命令为各处都能搜索到的:
1 | sudo docker run -d --name gitlab-runner --restart always \ |
运行成功后runner
就安装成功了,接下来需要配置与gitlab-ci
的连接信息,进入容器进行注册:
1 | docker exec -it gitlab-runner gitlab-ci-multi-runner register |
完成之后,重启runner
使注册生效。
1 | docker restart gitlab-runner |
踩坑
可以看到,我的gitlab-ci
文件中,使用了mvn
命令进行打包操作,而runner
镜像本身是没有java
环境及maven
环境的。所以会出现以下情况。
1 | Running with gitlab-runner 12.5.0 (577f813d) |
这里最好的方式,还是基于runner
镜像,编写一个dockerfile
,将java
和maven
环境安装到runner
中
(不过我发现的太晚了,又不想动手写dockerfile
…..)
于是我想了个骚方法- -。启动容器时,将java
和maven
的文件夹挂载到容器中去,于是我的启动命令变成了这样:
1 | docker run -d --name gitlab-runner --restart always \ |
好像起初一看没什么问题?一番操作后,还是报错找不到mvn
命令。于是进入到容器中:
1 | docker exec -it gitlab-runner /bin/sh |
原来容器内部的PATH
环境变并未发生更改,具体原因我猜测是docker run
命令中使用的$JAVA_HOME/bin
等并没有作为字符串传到容器中去,命令解析时是以宿主机的环境变量为准,而我宿主机并未配置该环境变量。
在我直接按照如下方式写的时候,是可以起效的:(不过谁会愿意这么些呢。。。又臭又长)1
-- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/jdk1.8.0_211/bin:/usr/local/apache-maven-3.6.3/bin
于是我去掉了对PATH变量的赋值,修改gitlabc-ci
文件为如下:
1 | stages: |
除script
的命令修改之外,可以看到我还添加了tags
标签,这里匹配的是注册runner
时,自己填写的tag
。可以在gitlab
的settings
页面进行修改。
如果不想配置tags
,可以进入settings --> CI/CD --> Runners Settings
,找到启用的runner
–> 编辑:
若yml
没有指定tags
,settings
中也没有勾选该配置,那么任务会一直处于pending
状态,提示找不到runner
。
最后再提一下关于docker
命令中 --privileged=true
,起初我没有添加该配置- -,虽然可以找到mvn
命令了,但ci
报错提示没有权限。虽然容器中默认是用的root
用户,但这个root
只具有容器内部的root
权限,针对挂载的目录,他并不能操作宿主机的文件,加上--privileged=true
后就可以了。
另:ci
发送指令给runner
时是自己创建了一个名为gitlab-runner
的用户(并非root
),所以如果有别的权限问题,可以考虑将文件移动到 /home/gitlab-runner
下操作,即可解决。