Gitlab-CI持续集成之Runner配置和CI脚本

buser

　　

gitlab-runner start -n jiukun_self_runner　　

gitlab-runner start -n jiukun_self2_runner　　

　　其中，-n为安装的服务名称，-d为工作路径，-c为配置文件，-u为执行用户（服务名称和执行用户必须指定，配置文件和工作路径可以使用默认路径）

　　其实，当我们执行上述安装命令时，gitlab-ci-multi-runner后台实际是将run命令写入/etc/systemd/system/jiukun_self_runner.service文件，使之成为一个单独的服务：

　　2.使用Shared Runner
　　使用share runner需要管理员权限，联系公司gitlab管理员，获取token。然后使用和Special Runner一样的方法注册成功。
　　进入任意项目的Runner页面，将看到以下内容：

　　这里我重复注册了两次，可以看到Runner无论是名字还是tag都可以重复，但是Runner的token却不相同，实际上区分不同的Runner工人只需要两样东西就是url和token。当然并不建议进行相同命名，不便于管理。
　　公司所有的项目默认都可以使用Shared Runner，而不需要重复配置。
　　1）好处：对于大多数Runner的配置其实是完全相同的（同样的executor，同样的配置文件和工作路径，同样的依赖环境），如果每个项目都去一个个注册不仅麻烦，而且不方便迁移，这时可以使用shared runner。
　　2）不足：如果一个项目的编译所需的exector等其他配置（配置文件有更多可选配置），并且和其他项目需要单独管理，这时最好使用Special Runner，并锁定该Runner为项目本身使用，单独管理。

　　五、管理Runner
　　1.注册的runner列表
　　

gitlab-runner list \--config "/etc/gitlab-runner/config_jiukun_test.toml"　　

　　2.查看runner连接状态
　　

gitlab-runner verify \--config "/etc/gitlab-runner/config_jiukun_test.toml"　　

　　3.取消注册（移除）
　　

gitlab-runner unregistry \--url http://gitlab.xxxxxx.com/ci \　　--token 9c1bb50065661ba766023016f6ebf2
　　

　　不能直接在project的web端进行remove操作，否则这里会执行失败
　　4管理gitlab-runner服务
　　

gitlab-runner status \　　

-n jiukun_self_runner.service　　

　　不指定服务名，则默认为gitlab
-runner服务　　

　　
gitlab
-runner stop \　　

-n jiukun_self_runner.service　　

　　
gitlab
-runner restart \　　

-n jiukun_self_runner.service　　

　　
gitlab
-runner uninstall \　　

-n jiukun_self_runner.service　　

　　

执行uninstall会卸载该服务，与之对应的runner将无法通过该服务运行，请确保对应的CI任务已停止。　　

　　六、集成脚本
　　将集成脚本命名为.gitlab-ci.yml或者.gitlab-ci.yaml，放置在对应项目仓库分支的根目录下。

　　1.  yaml语法
　　大小写敏感、使用缩进代表层级、不允许使用Tab缩进，只能使用空格，缩进并无统一限制，但同级关系内要保持对齐即可。#代表注释。
　　语言格式里存在减号和冒号这些特殊字符，因此要注意千万别写成中文的字符格式。
　　减号对应的是数组，冒号对应的是键值对（对象）。
　　2. 关键词
　　1）image
　　如果使用docker作为Runner的executor，并且没有设置默认的镜像，此处需要设置镜像；不使用可以省略
　　2）sevices
　　如果使用docker集群服务，可以直接调用服务；不使用可以省略
　　3）stages
　　定义各个阶段名称，如果省略，CI默认为三个阶段

　　每个job都必须定义其所属的阶段，如果不定义，默认均属于build阶段；同阶段任务并行对待，上一阶段所有任务执行成功，才会继续执行下一阶段；语句依次执行，如果某一语句执行失败，将返回错误码，并宣告CI失败。
　　如果定义stages，则job中的stage必须与之相对应。
　　4）before_script
　　定义在所有脚本运行之前执行的语句
　　5）after_script
　　定义在所有脚本运行之后执行的语句
　　6）variables
　　定义环境变量

　　7）cache
　　定义下个job会使用到的文件或内容
　　3. Jobs
　　.gitlab-ci.yml脚本内容的主体为一个个job，没有数量限制，每个Job名称可以相同也可以不同（最好不要相同），可以大小写；每个Job内部至少有一个关键词。常用关键词如下
　　1）stage
　　和脚本全局stages对应（如果全局未定义，可使用默认）
　　2）image、services、variables
　　同全局关键词
　　3）only
　　规定该脚本响应分支（项目其他分支不会触发该脚本；如果不定义，会检测所有分支；与之相反的关键词是except）
　　4）before_script、after_script
　　同全局关键词（注意，如果同时存在，会覆盖全局关键词对应列表内容）
　　5）script
　　脚本主体，使用方法和在shell内一样，将在对应executor内运行一个shell环境，执行脚本内容。每个Job的shell环境不同（Job结束，该环境自动关闭）。
　　6）tags
　　指定Runner的标签（通常一个项目有很多Runner，依靠tag区分）
　　7）artifacts
　　指定Job的产出文件路径，如果该关键词设定，可以直接在pipeline页面下载该文件
　　8）when
　　默认一个job只有在上一阶段所有job成功才会执行，通过when可以改，通常用来清理环境使用，以免失败后无法清理，有四种可选参数。
　　on_success（上一阶段所有Job成功才执行）
　　on_failure（上一阶段任意Job失败就执行）
　　always（总是执行）
　　manual（此阶段由UI界面交互执行）
　　备注：以上纯属原创，学习来源为gitlab-runner官方中文文档、gitlab-runner英文文档、gitlab-ci英文文档。如需转载请注明出处，后续继续完善。