初探 Gitlab CI

公司内部使用的是 Gitlab 仓库套件管理项目代码，之前把玩过的 Drone CI 是可以很好的支持 Gitlab 的，前提是需要在 Gitlab 中申请一个管理员权限的密钥方便其读取项目目录并设置 Webhook 等操作。而公司的 Gitlab 仓库权限管理很严格，我暂时还没有权限申请这个就只能放弃了。最近他们使用 Gitlab 8 （不要问我为什么是这么早的版本毕竟我们一直都在用7的）搭建了一个新的仓库，自带支持了 Gitlab CI 的功能，于是就拿来试了下。

Gitlab CI 整个流程和 Drone 以及流行的 Travis CI 都是比较类似的，通过在项目中添加一个 .gitlab-ci.yml 的配置文件，配置文件中描述构建流水线来执行任务。有的同学说为什么不试试 Jenkins，那 Jenkins 的配置那么的复杂反正我是拒绝的。

安装 Gitlab Runner

由于构建任务是一个非常消耗性能的行为，所以 Gitlab 将构建任务的执行单独拆分出来，Gitlab 本身只是用来派发任务，而 Gitlab Runner 脚本才是用来真正执行任务的。这样做能将性能压力从 Gitlab 中拆分出来，不影响主仓库的正常运行，同时也为支持多机分布式构建任务打下了基础。

安装 Gitlab Runner 很简单，不过需要注意的是不同的版本对应的是不同的 Runner。Gitlab 10- 对应的版本叫 Gitlab CI Multi Runner，Gitlab 10+ 之后 Runner 修改了名字为 Gitlab Runner 了。Gitlab Runner 的安装教程直接参考官方文档即可。如果是想我一样的老版本需要安装 Gitlab CI Multi Runner 的话需要将第一步的编译文件下载地址换成老版本的地址，具体的地址可以访问 Gitlab CI Multi Runner 1.11.5 这里查到。

新旧版本主要是 RESTful 接口发生了变化，如果你的 Gitlab 是老版本的，Gitlab Runner 是新版本的话，注册的时候就会报 405 的错误。

ERROR: Registering runner... failed                 runner=<token> status=405 Method Not Allowed
PANIC: Failed to register this runner. Perhaps you are having network problem

注册 Gitlab Runner

安装启动完毕之后就需要将 Gitlab Runner 与 Gitlab 进行关联了。

• 打开你 GitLab 中的项目页面，在项目设置中找到 runners
• 运行 sudo gitlab-ci-multi-runner register
• 输入 CI URL
• 输入 Token
• 输入 Runner 的名字
• 选择 Runner 的类型，简单起见还是选 Shell 吧

在注册的过程中除了会让你输入 Gitlab CI URL 和仓库 Token 之外，还会让你选择是否只允许 git tag 操作才能触发构建任务，以及是否只允许本仓库独享该 Runner。而 Runner 类型可选的也比较多，总的分为实体机执行（SSH，Shell）和虚拟机执行（VirtualBox，Parallels，Docker，Kubernetes）两大类。其中虚拟机执行需要配置虚拟机相关的一些参数，好处是每次执行都是相对干净的环境，多次执行不会受到影响。关于各种 Runner 执行器的区别可以参考 Gitlab 官网文档 Excutors，有表格非常详细的讲述了各种执行器的区别和优缺点。

我这里选择了最简单的 Shell 类型，不需要输入任何参数即可完成注册。Shell 注册类型本质上就是使用 Gitlab Runner 对应的启动用户（默认是 gitlab-runner）执行对应的构建任务命令。所以执行过程中可能需要注意一下权限之类的问题，如果发现任务执行失败了也可以手动上机器切换到对应账户执行下任务命令调试。Runner 注册完成之后你就可以在 Gitlab 仓库 http://<仓库地址>/runners 页面看到你刚注册的 Runner 了。

编写构建任务

环境都部署好之后接下来就是编写构建任务了。我尝试编写了一个非常简单的构建任务。首先我们在仓库的根目录下新建一个 .gitlab-ci.yml 的文件，文件内容如下：

stages:
  - deploy_test

deploy:
  stage: deploy_test
  only:
    - test
  script:
    - sh ./bin/deploy.sh

stages 定义该仓库构建任务里有一个 deploy_test 的构建接单（可以指定多个构建阶段），多个构建阶段会按照先后顺序执行任务。然后我定义了一个名为 deploy 的任务，这个任务属于 deploy_test 构建阶段。且该任务仅在 test 分支发生提交的时候才会触发，触发后会执行 sh ./bin/deploy.sh 这个 shell 命令。在 deploy.sh 这个脚本中我编写了更新测试环境的相关的代码，最终完成了只要 test 分支提交代码就自动帮我们更新测试环境的目的。

怎么样？非常简单吧。这就是一个非常简单的构建任务编写的示例了。除了以上关键字之外，.gitlab-ci.yml 还支持其他的一些关键字，具体可以参考文档 Configuration of your jobs with .gitlab-ci.yml。

后记

本文主要是讲了一下如何部署 Runner 以及简单的构建任务的编写。Runner 注册的话图简单我这里选择了 Shell，那其实还是更推荐大家使用 Docker 之类的虚拟环境来执行这样构建任务的环境因素影响能降低到最小。而构建任务编写这块我也仅仅只是举例了一个自动更新测试环境而已，其实大家还可以做非常多的事情。例如提交代码后自动执行测试、提交代码后自动执行编译构建、自动发送相关邮件通知等等。大家可以发挥想象尽情使用 CI 完成一些自动化操作。