目录
- 持续集成&持续集成工具的介绍
- gitlab-ci runner的基本配置方法（mac版本）
持续集成
CI，Continuous Integration，持续集成，是软件开发过程中一个非常重要的环节，在互联网敏捷开发的过程中，持续集成通常用来进行日常编译和自动化测试，来保证及时发现提交的问题，避免影响项目进度。
通常持续集成的过程包括：
- 提交（合并）代码
- 编译
- 测试
- 发布
不同的项目可能步骤有所不同，一些更加规范的公司的项目可能会加入静态代码检查，也有不少的小项目迫于进度和QA的工作压力，可能连测试过程都没有。
持续集成工具
CI工具有很多，目前最为常用应该是Jenkins。Jenkins通常包括一个master和很多个slave。master用于配置和组织节点、任务，slave则用来真正执行配置好的任务。因为用户群体的庞大，Jenkins上的各种插件，尤其是很多可视化插件都非常丰富，可以帮助很多新手快速配置所需的任务。
gitlab-ci是git官方的持续集成工具，在Git工程管理页面上，也有专门的CI配置和展示页。
Github上许多优秀的开源项目的Readme.md中，可以看到有如下图中“build|passing”的图标，就是通过markdown元素引用了当前版本CI/CD的结果的展示。
随着代码更多地通过Git进行管理，gitlab-ci也成为了常见的CI平台。就我理解，gitlab-ci是一个简易版的jenkins，git服务器兼任了Jenkins master的功能，而我只需要准备好一个slave即可。而且，gitlab-ci的runner支持多重环境，尤其是Docker还有专属的配置支持。配置过程也非常的简便无脑，比起Jenkins的slave配置可以说是完胜了。
之前我一直都是在公司的Jenkins服务平台上做CI（其实也没做过几个）的，由于Jenkins权限管控的问题，不方便在slave上尝试和排查环境问题（可以看我之前的oclint出现环境问题的排查）。刚好前段时间被其他小组的项目安利了gitlab-ci，因此就想学习一下和尝试一下。
我的CI目标
“先给自己定个小目标”，赚他一个亿。阿不，能编译通过就好。
因为我所在的项目比较复杂，多人（>10）协同开发多个项目，这些项目的编译产物被同一个父工程所引用。但是开发的规范性不是很好，提交比较随意，又没有规范约束，提了多次仍然时不时出现提交错误或遗漏导致影响到其他同事工作进度的情况。
我希望通过CI的方式，能够快速验证每次提交的可用性。当然如果后续的打包提交和自动化测试也能通过CI完成就更完美了。所以，先给自己定一个小目标，对所有相关工程的每次提交都进行打包，并返回正确的结果。
当然啦，这个目标在本文中还没有被用到，后面我就会为这个“小目标”付出“惨重的代价”。
gitlab-ci runner的安装与配置
有兴趣了解原理的欢迎大家直接搜索gitlab-ci的官方文档去照着做。我这里提供mac上的安装攻略（因为有iOS项目），基本都是按照官方文档走的，也会分享由于太想当然踩到的几个坑。
简单介绍一下runner。正如我前文所说，runner可以理解为是Jenkins的slave，机器（或docker）通过runner程序与git服务器进行通信，当有新的任务发布到当前runner时，runner会执行.gitlab-ci.yml所定义的CI指令。
runner可以分为三种，Shared Runners，Specific Runners和Group Runners。Gitlab上可以使用官方的Shared Runners，创建Shared Runners需要Git管理员（不是仓库管理员）的权限。而Group Runners则是在Group中共享runner，需要Group的master以上的权限。Specific Runners是指定给当前项目使用的，这是大部分我们自己创建的runner的属性。具体的说明可以自行阅读参考文档[3]。
1. 使用Homebrew 安装gitlab-runner
Homebrew是mac上一个近乎官方的安装工具了，直接执行就可以安装最新的稳定版gitlab-runner，我使用的是11.2.0。
brew install gitlab-runner
注意！有些文章会告诉你紧接着执行gitlab-runner install，但这并不是安装gitlab-runner的指令，这是service的指令，不要执行，不要执行，不要执行，重要的事情说3遍，后续会解释原因
2. 注册runner
首先，假设你已经有了一个项目，并且需要至少master权限。这个项目可以在github，gitlab，或者私有git。我就以公司的私有git为例来说明了。
打开settings->CI/CD页面，选择第二项Runners settings，左侧会显示与当前项目相关的参数。
然后执行
gitlab-runner register
依次输入项目中的参数，如下图（gitr是我设置的快捷输入，即为gitlab-runner）
- url：私有git的路径
- token：项目的token，用于关联runner和项目
- name：runner的名字，用于区分runner
- tags：用于匹配任务（jobs）和执行任务的设备（runners）
- executor：执行环境
其中url和token在项目的CI配置页上可以找到。name只是用来区分两个runner，没有特殊的作用。tags这个属性，job和runner都有，用来匹配任务和执行任务的runner。job的tags属性下一篇会提到，也可以自行查阅.gitlab-ci.yml的语法。runner的tag可以有多个，注册时用逗号（comma）分隔即可。当某个job的tag是当前runner tags的一个子集时，这个job就可以被分配到当前runner上执行。
举个栗子
runner的tag设为：ios, macos, android
job的tag设为：ios，或ios，macos就可以在这个runner上执行。
job的tag设为：linux，这个job就不会被分配到这个runner上。
job的tag设为：ios, linux，这个job也不会被分配到这个runner上。
executor就是执行job的环境，通常我们都会选择Shell，如果有其他需要的也可以自行查阅文档。
需要注意的是，runner执行的环境是非常干净的，像类似ANDROID_HOME的变量都需要通过shell指令export xxx=xxx在执行时输入，而不是使用设备上的环境。
当我们完成设置以后，可以通过vi ~/.gitlab-runner/config.toml打开runner的配置文件，刚才所填写的信息都会记录在其中。如果配置了多个runner，就会像图中一样，出现两个runners的section。
3. run-single调试runner
gitlab-runner run-single可以启动单个runner，并指定一些配置，用来作为调试。必须要指定的参数其实就是之前注册的时候需要填写的这些参数，其他的可以通过gitlab-runner run-single -h来查看。
4. install & start service
还记得第一步我说的不要执行gitlab-runner install吗，终于轮到他来表演了。runner作为等待被派发任务的设备，如果只能通过run或者run-single来前台执行就太蠢了。gitlab-runner也提供了service，用来后台响应git服务器的任务分发。
在你希望runnerClone代码并执行CI操作的目录执行gitlab-runner install，service就安装成功了。
会有人按照教程一顿操作（猛如虎）,install & start，结果连git clone下来的目录在哪都找不到（嗯，说的就是我）。其实runner的workspace就在你执行gitlab-runner install的目录下。
然后执行gitlab-runner start就启用了service。此命令的执行目录不会影响任何配置，并且每次开机默认都是自动启动service的，可以说非常的贴心。
通过gitlab-runner start启动的service包括了在config.toml文件中配置的所有的runners。
完成上述操作以后，git runner的配置就完成啦，下一章会通过一个例子简单讲一讲.gitlab-ci.yml文件的语法和一个小小的尝试
本系列文章列表
(一) gitlab-ci的简易入门——runners（本文）
(二) gitlab-ci的简易入门——.gitlab-ci.yml
(三) 一个简单iOS工程的成功尝试
(四) 困境中用git-submodule和git-lfs优化工程
(五) 复杂工程的gitlab-ci初成
参考文章
[1] gitlab-ci官方文档
[2] Homebrew安装
[3] gitlab-runner 文档