gitlab ci介绍和应用

gitlab ci介绍和应用

一：流程

二：介绍

(1) 通过在项目根目录下配置.gitlab-ci.yml文件，可以控制ci流程的不同阶段，例如install/检查/编译/部署服务器。gitlab平台会扫描.gitlab-ci.yml文件，并据此处理ci流程

(2) ci流程在每次团队成员push/merge后之后触发。每当你push/merge一次，gitlab-ci都会检查项目下有没有.gitlab-ci.yml文件，如果有，它会执行你在里面编写的脚本，并完整地走一遍从intall => eslint检查=>编译 =>部署服务器的流程

(3)gitlab-ci提供了指定ci运行平台的机制，它提供了一个叫gitlab-runner的软件，只要在对应的平台(机器或docker)上下载并运行这个命令行软件，并输入从gitlab交互界面获取的token,就可以把当前机器和对应的gitlab-ci流程绑定，也即：每次跑ci都在这个平台上进行。

(4).gitlab-ci的所有流程都是可视化的，每个流程节点的状态可以在gitlab的交互界面上看到，包括执行成功或失败。如下图所示,因为它的执行看上去就和多节管道一样，所以我们通常用“pipeLine”来称呼它

(5).不同push/merge所触发的CI流程不会互相影响，也就是说，你的一次push引发的CI流程并不会因为接下来另一位同事的push而阻断，它们是互不影响的。这一个特点方便让测试同学根据不同版本进行测试。

(6)pipeline不仅能被动触发，也是可以手动触发的。

一个Pipleline有若干个stage,每个stage上有至少一个Job，如下图所示：

Runner

Runner可以理解为：在特定机器上根据项目的.gitlab-ci.yml文件，对项目执行pipeline的程序。Runner可以分为两种： Specific Runner 和 Shared Runner

• Shared Runner是Gitlab平台提供的免费使用的runner程序，它由Google云平台提供支持，每个开发团队有十几个。对于公共开源项目是免费使用的，如果是私人项目则有每月2000分钟的CI时间上限。
• Specific Runner是我们自定义的，在自己选择的机器上运行的runner程序，gitlab给我们提供了一个叫gitlab-runner的命令行软件，只要在对应机器上下载安装这个软件，并且运行gitlab-runner register命令，然后输入从gitlab-ci交互界面获取的token进行注册, 就可以在自己的机器上远程运行pipeline程序了

YML是一种编写配置文件的语言，比JSON更为简洁和方便

stages定义在YML文件的最外层，它的值是一个数组，用于定义一个pipeline不同的流程节点

例如我们定义如下:

stages: # 分段 - install - eslint - build - deploy

则在Gitlab交互界面中能够看到如下展示

Job是pipeline的任务节点，它构成了pipeline的基本单元

而stage/script/tags这三个关键字，都是作为Job的子属性来使用的,如下所示，install就是我们定义的一个Job

install: tags: - sss stage: install script: - npm install

stage

是一个字符串，且是stages数组的一个子项，表示的是当前的pipeline节点。

当前stage的执行情况能在交互面板上能看的清清楚楚：

• 正在执行是蓝色
• 尚未执行是灰色
• 执行成功是绿色
• 执行失败是红色

script

它是当前pipeline节点运行的shell脚本（以项目根目录为上下文执行）。

这个script是我们控制CI流程的核心，我们所有的工作：从安装，编译到部署都是通过script中定义的shell脚本来完成的。

如果脚本执行成功，pipeline就会进入下一个Job节点，如果执行失败那么pipeline就会终止

tags

tags是当前Job的标记，这个tags关键字是很重要，因为gitlab的runner会通过tags去判断能否执行当前这个Job

例如我们在gitlab的面板中能看到当前激活的runner的信息

Gitlab项目首页=> setting => CI/CD => Runners

##查看状态