提及到持续集成工具，想到的有jenkins、buildbot、gitlab ci，本文就来讲讲gitlab ci~
首先先扫盲：
什么是持续集成？
持续集成指的是，频繁地（一天多次）将代码集成到主干。
持续集成的好处主要有两个：
快速发现错误：
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
防止分支大幅偏离主干：
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
简单总结：
减少风险、减少重复过程、项目更加透明
常见的持续集成系统组成
一个完整的构建系统必须包括：
- 一个自动构建过程，包括自动编译、分发、部署和测试等。
- 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
- 一个持续集成服务器
GitLab CI介绍
GitLab CI
GitLab CI 是 GitLab 提供的持续集成服务，只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件， 并为该项目指派一个Runner，当有合并请求或者 push的时候就会触发build。
GitLab-Runner
这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。
GitLab-CI浏览过项目里的.gitlab-ci.yml文件之后，根据里面的规则，分配到各个Runner来运行相应的脚本script。
.gitlab-ci.yml
.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。
默认有3个[stages(阶段)]: build、test、deploy。
Pipelines
Pipelines是定义于.gitlab-ci.yml中的不同阶段的不同任务。
把Pipelines理解为流水线，流水线包含有多个阶段（stages），每个阶段包含有一个或多个工序（jobs），
比如先购料、组装、测试、包装再上线销售，每一次push或者MR都要经过流水线之后才可以合格出厂。
而.gitlab-ci.yml正是定义了这条流水线有哪些阶段，每个阶段要做什么~
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages
Stages 表示构建阶段，说白了就是上面提到的流程。
我们可以在一次 Pipeline 中定义多个 Stages，每个Stage可以完成不同的任务。
Stages有下面的特点：
所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败
因此，Stages 和 Pipeline 的关系就是：
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
Jobs
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。
我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
相同 Stage 中的 Jobs 会并行执行
相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败
所以，Jobs 和 Stage 的关系图就是：
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
简单的说，要让CI工作可总结为以下几点:
1）在仓库根目录创建一个名为.gitlab-ci.yml 的文件
2）为该项目配置一个Runner
完成上面的步骤后，每次push代码到Git仓库， Runner就会自动开始pipeline。
CI基本原理
持续集成基本原理实际上非常简单：
- 1.检测到 git 有新的代码提交（定时检测或主动触发），生成任务
- 2.agent（真正干活的进程，可以分布在多台机器） 领取任务，拉取代码，运行一段脚本（无论是单元测试还是 APP 打包，都可以用脚本完成）
- 3.展示结果：成功与否、测试覆盖率、apk ipa 下载链接等
安装及配置
1.安装runner
本文以win10举例：
首先，下载gitlab-ci-multi-runner-windows-amd64，并将其放到C:\CI
下载地址： https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-windows-amd64.exe
Centos： 安装gitlab-ci-multi-runner：
-
添加yum源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
执行后长这样：
只要不报错或者提示找不到的话，就可以了，那接下来就安装了~
yum install gitlab-ci-multi-runner
注册等步骤则跟Windows一致~ 2.获取gitlab的runners
点击一个项目->Settings->CI/CD->Runners setting,点击Expand
3.配置runner
回到刚刚配置的目录，楼主是在C:\CI
执行下面的命令：
gitlab-ci-multi-runner-windows-amd64.exe register
如果是Linux则如下：
gitlab-ci-multi-runner register
然后会要求输入一堆东西，如下图：
1）输入Gitlab CI地址
2）输入项目CI的token
3）输入Runner的描述
4）输入Runner的标签
5）是否运行无标记的构，默认false，后面可以改
6）是否将Runner跟当前项目绑定，默认false，如果不绑定，即为共享runner，后面可以改~
7）输入Runner执行语言
执行完后，会发现CI目录会多了个config.toml的文件，里面就是刚刚的配置信息~
如果是Linux，Runner信息放哪里呢？
- 如果是以root用户身份运行gitlab-ci-multi-runner register，那么配置文件默认是/etc/gitlab-runner/config.toml
- 如果是以非root用户身份运行gitlab-ci-multi-runner register，那么配置文件默认是~/.gitlab-runner/config.toml
- 又或者是在当前工作目录下./config.toml
下面需要开启runner服务~
在CI目录下，分别输入install跟start命令：
gitlab-ci-multi-runner-windows-amd64.exe install
gitlab-ci-multi-runner-windows-amd64.exe start
如果需要停止，把start修改成stop即可~
输入完毕后，只要没有报错，则说明成功，然后回到gitlab项目-Runner Settings上，会发现多了个runner的信息：
到此为止，runner设置完成了~
关于其他平台的安装到注册，详情请看官网详细介绍，大同小异： https://docs.gitlab.com/runner/install/
4）.gitlab-ci.yml
如上面介绍的一样，.gitlab-ci.yml 文件定义GitLab runner要做哪些操作；
它位于项目的根目录。
一个简单的.gitlab-ci.yml
stages:
- test
job1:
stage: test
script:
- echo "jb1111112222"
很简单，定义了一个叫job1的jobs，stages里面是定义任务执行的顺序，但上面体现不出来，而这个job1里面就是输出jb1111112222这串玩意~
注意：.gitlab-ci.yml是一个YAML文件，所以必须要格外注意锁紧。使用空格，而不是tabs。
假如是这样呢？
# 定义 stages
stages:
- build
- test
# 定义 job
job1:
stage: test
script:
- echo "I am job1"
- echo "I am in test stage"
# 定义 job
job2:
stage: build
script:
- echo "I am job2"
- echo "I am in build stage"
理所当然的，上面的运行结果就是这样：
I am job2
I am in build stage
I am job1
I am in test stage
根据在 stages 中的定义，build 阶段要在 test 阶段之前运行，所以 stage:build 的 jobs 会先运行，
之后才会运行 stage:test 的 jobs。
文件创建好了，内容也定义好了，然后需要添加到git仓库~
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
下面为常用的关键字信息，一般熟悉就够用了：
有关更多关键字信息，请看下面的文章： https://segmentfault.com/a/1190000010442764#articleHeader5
5）查看pipeline和jobs的状态
成功的配置好Runner后，你应该查看最后一次提交后的状态，从pending、到执行中、成功或失败。
点击进入具体job的执行情况：
gitlab CI大致就介绍完毕了，剩下的就是定义.gitlab-ci.yml文件，做想执行的事情~
遇到的问题
1）gitlab ci结果显示乱码
暂时没找到解决方案
2）runner无端端离线，然后一直start失败，一直提示gitlab-runner: Service is running!， 即使重装gitlab-runner也不能解决问题
现象：
输入gitlab-runner start,卡住很久，然后没有任何日志输出
解决方案: 这种问题，第一思路就是找error log，但是找了很久都没找到error log文件；
最后晚上找到一条命令：
journalctl -u gitlab-runner
输入后，会显示log：
然后再输入:
gitlab-runner start
gitlab-runner status
然后就能看到久违的is running!!
感动啊~为了看到这个提示，都不知道找了多少方法，果然，看log才是王道~
3）gitlab 上一直显示pending
原因： 在注册gitlab runner的时候，有一步是：
那没有标记tag的代码提交时不会触发gitlab runner，测试阶段，最好填写true；
那如果是已经创建好的runner，不想重新注册，怎么办？
打开对应的runner界面，点击编辑图标，把run untagged jobs勾上即可；
步骤： projects-settings-CI/CD-Runners settings
这样，就不会再是pending的状态了~
4）权限不够，无法创建目录
这个目录就是问题2手动创建的目录，手动chmod 777 /home/gitlab-runner即可
谢谢大家~
