CI(持续集成)——II

这篇文章作为上一篇的落地实现，会简单介绍一下一些相关的概念以及基本的使用。采用的实现方案是GitLab结合Runner。

GitLab安装教程

https://blog.csdn.net/sinat_33755317/article/details/84191167

Runner

什么是Runner

Runner是用来运行job(build、push等过程)并且将运行的结果发送给Gitlab，方便用户查看结果的一个开源项目，它与Gitlab内置的Gitlab CI结合完成对应的job

Gitlab CI:是一套配合Gitlab使用的持续集成系统(也还有其他的持续集成系统，比如Jenkins)，目前8.0以后的gitlab版本默认集成Gitlab CI

安装&注册

https://blog.csdn.net/sinat_33755317/article/details/84192074

Runner分类

specific runner

• specific runner只有自己可以使用，即使在同一项目组也无法使用，因为是通过token创建的个人环境
• share runner & group runner
  供群组内部所有成员使用，管理员才有权限进行相应的配置

Executor

用来执行job，并返回执行结果，有下面几个分类

Executor分类

• SSH
  在所有的executor中，对SSH的支持最少，可以使Gitlab Runner连接其他外部服务器并在其他服务器上执行build过程
• shell
  配置最简单的一种，所有构建所需要的依赖都会在安装Runner时安装好。这就意味着可以在任何一个安装有Runner的本地机器的地方执行
• Virtual Machine Executor (VirtualBox / Parallels)
  顾名思义，这种类型的executor允许在已经创建好的虚拟机上执行build操作，这一类型可以使操作在不同操作系统上执行，以为它能够使Gitlab Runner连接Windows、Linux以及其他操作系统的虚拟机并在其上运行
• docker executor
  是比较好的方式，因为使用这种方式使用更加简便的方式(构建项目需要的所有依赖会统一放置在镜像中)能使得build环境更加干净，使用依赖服务，docker executor会让创建构建环境的过程更加容易
• docker machine
  是一个特殊版本的docker executor，因为它支持自动调度。因为它会像普通的docker executor一样工作，但是会按需创建构建主机
• kubernetes executor
  这种方式允许使用现有的kubernetes集群来进行构建操作，这种方式会通过调用kubernetes API为每个Gitlab CI job创建新的Pod(兼具构建容器和服务容器)

使用

使用Gitlab实现自动集成有两个条件，
①在项目根目录下有.gitlab-ci.yml文件，可以使用其他文件名，但是需要自行配置
配置页面：项目下找到settings -> CI/CD -> General pipelines展开 -> custom CI config path(默认使用.gitlab-ci.yml)
②为该项目配置了runner，如果没有配置的话，在执行的时候会出现“stuck”样的标签来表示该项目未配置runner
.gitlab-ci.yml:这个文件的作用是告诉runner怎么执行集成操作，当执行push操作时，会在项目根目录下查找该文件

.gitlab-ci.yml文件编写

一些基本概念

pipeline

相当于一次构建任务，里面可以包括多个流程，如build、test等

stages：

翻译成阶段比较合适，用来全局定义job(个人理解：就是提前声明好stage,在下面定义的时候就可以使用stages下定义好的)，stages下定义的元素决定了job的执行顺序

1. 具有同样stage的job会平行执行
2. 当前一个stage必须成功执行完才会执行下一个

for example:

stages:
  - build
  - test
  - deploy

上面的代码块定义了三个阶段

1. 所有stage为build的job会平行执行
2. 当stage为build的所有job都成功执行完，stage为test的job才会执行
3. 同上，所有stage为test的job全部执行完，stage为deploy的job才会执行
4. 当stage为deploy的job全部执行完，本次提交就会标记成pass，如果出现其中一个job失败，那么本次操作就会失败，而且之后的job都不会执行

• stages结点的注意事项
  1. 如果在.gitlab-ci.yml中没有定义stages也是可以的，提供了三个默认的stage，分别是build、test和deploy
  2. 如果一个job没有指定stage，那么这个job会指定stage为test

stage

stage定义了每一个job并且依赖于stages，它可以使一组job使用不同的stage

job

表示具体的构建工作，表示某个stage里执行的具体工作，同一个stage可以对应多个job，相同stage的job会并行执行，这个在前面说过了，所以可以有下面的图

script

• script是唯一一个定义job必须的关键字，它是一个由runner执行的shell脚本，但是有时候需要加双引号，当使用下面的特殊字符时需要注意：

:, {, }, [, ], ,, &, *, #, ?, |, -, <, >, =, !, %, @, `

only & expect

这两个参数是用来设置job创建时机的

• only - job在哪个分支或者tag(标签)发生变动时运行
• except - 与only相反

使用规则：

cache

cache && Job.cache
要求: GitLab Runner 0.7.0+

定义需要缓存的文件。每个 Job 开始的时候，Runner 都会删掉 .gitignore 里面的文件。如果有些文件 (如 node_modules/) 需要多个 Jobs 共用的话，我们只能让每个 Job 都先执行一遍 npm install。
这样很不方便，因此我们需要对这些文件进行缓存。缓存了的文件除了可以跨 Jobs 使用外，还可以跨 Pipeline 使用。

注意点

Runner的版本最好和Gitlab的版本一致，即使能够正常使用，但是可能会有隐藏的问题

附：

• GitLab Runner官方文档
  https://docs.gitlab.com/runner/
• .gitlab-ci.yml官方文档
  https://docs.gitlab.com/ee/ci/yaml/README.html