主要内容
使用gitlab实现每次提交代码后自动编译并发布
安装gitlab runner
一般来说gitlab runner推荐与gitlab子版本保持一致,即gitlab版本为x.y.z时安装x.y.w版本的gitlab-runner,在有公网的环境下推荐通过操作系统的包管理器直接安装参考官方教程,如果gitlab版本比较旧可以在这个网站找到历史版本或者参考此处找到合适的版本, 注意:gitlab和gitlab runner版本并非一一对应
注册gitlab runner
首先登录gitlab在获取一个runner注册码,在安装runner的机器上执行sudo gitlab-runner register
按照提示输入gitlab地址,注册码,runner的名字,runner的tag,runner的执行命令的方式,如果这里选择了docker,还会要求提供一个基础镜像用于后续的打包,其中runner的名字和tag可以后续在gitlab界面上修改,命令执行方式需要修改runner的配置文件.最后在打开gitlab上的项目,在设置-CICD-Runner中查看是否能看到刚才注册的runner
根据注册方式不同gitlab runner使用权限分为以下几种
- 共享runner: 一般由gitlab管理员注册,可以在整个gitlab实例上共享,在项目的设置中默认禁用
- 群组runner: 与某一个群组绑定,可以在群组内共享,在项目的设置中默认启用
- 专用runner: 与某一个具体的项目绑定,只能在这个项目上使用
.gitlab-ci.yml
文件
gitlab runner会根据.gitlab-ci.yml
文件(本节内简称文件)中的配置来执行相应的打包,部署命令.runner会根据每个文件创建一个流水线,流水线中包含多个作业,每个作业属于一个阶段.一个流水线包含哪些阶段是在文件的开头通过stages
定义,例如
1 | stages: |
阶段之间根据文件中定义的顺序具有前后依赖关系,前一个阶段所有任务成功结束后才会执行下一个阶段的任务.在阶段后,可以定义作业,作业没有固定的起始标签,但是有多个二级标签,例如
1 | maven-build: |
定义了一个叫做maven-build
的任务,这个任务属于build
阶段,执行的命令是mvn clean compile
具体的yaml关键字可以在这里查看
一些坑
- 在每个job开始前会清理未加入git版本控制的文件,所以如果部署比较简单可以考虑将所有步骤放在一个任务里执行
- 原因同上,对于nodejs,如果是在内网环境且没有node镜像的话就无法打包了
- 如果使用多个步骤,需要先将打包生成的文件移动到其他目录或者使用
artifacts
来保留,但这这又引出另一个问题,artifacts
标签定义的文件是会被runner上传到gitlab的,可能会遇到文件大小超限的问题(nginx,gitlab,防火墙策略等)ERROR : Uploading artiifact Entity Largetoken=xxxx FATAL:too large ERROR
- linux下安装gitlab runner的用户如果不是gitlab-runner用户则可能导致job一直卡在无可用的执行器的状态
- 在linux下安装需要开放8888端口(默认)
参考文章:https://www.cnblogs.com/Arunoido/p/16978188.html
https://segmentfault.com/q/1010000040640168?bd_source_light=4746641
https://zhuanlan.zhihu.com/p/559909411
https://blog.csdn.net/weixin_46192667/article/details/125081702
https://blog.csdn.net/clover661/article/details/123411439
https://stackoverflow.com/questions/56070922/in-gitlabs-ci-cd-system-how-do-i-prevent-a-job-from-running-if-its-in-my-fork
http://www.ttlsa.com/auto/gitlab-cicd-gitlab-ci-yml-configuration-tasks-detailed/