前言

本文操作目标：搭建GitLab以及使用GitLab的CI Runner服务，对项目进行测试。
操作过一次，才知道并非想像中的那么复杂，也没有像想中的那么简单。

在搭建自己的 CI Runner 之前，需要先明确一些概念：

Continuous Integration(持续集成)

CI 的全称是 Continuous Integration (持续集成)，是 extreme programming (极限编程) 的一部分。我们常用 CI 来做一些自动化工作，这种自动化工作会运行在一台集中的机器上，比如程序的打包，单元测试，部署等。这种构建方式避免了了打包环境差异引动的错误，并且通过 Gitlab 的 hook, 在代码提交的各个环节自动地完成一系列的构建工作。

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

GitLab-CI

GitLab-CI就是一套配合GitLab使用的持续集成系统（当然，还有其它的持续集成系统，同样可以配合GitLab使用，比如Jenkins）。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

GitLab-Runner

那GitLab-Runner又是什么东东呢？与GitLab-CI有什么关系呢？

GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时

GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

所以，GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下：Runner就像一个个的工人，而GitLab-CI就是这些工人的一个管理中心，所有工人都要在GitLab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示：

image.png

Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。

Runner类型

GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。

Shared Runner：这种Runner是所有工程都能够用的。只有系统管理员能够创建Shared Runner。

Specific Runner：这种Runner只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

准备工作：

Centos7机器，2台。 一台安装GitLab和Runner，一台用来充当Runner的操作机。

Docker安装

GitLab功能十在是太丰富，安装的服务太多。服务器资源紧缺，所以一台服务器上用Docker来做安装测试喽。

Docker的安装及基础使用，本章不做阐述。

GitLab安装

从Gitblit转移至GitLab，发现其复杂度真不是一个数量级的。如果不需要在源码上做很多服务，还是Gitblit用的随心。
使用Docker安装GitLab，找了一个9.x的中文版

$ docker pull docker.io/twang2218/gitlab-ce-zh
$ docker images
docker.io/twang2218/gitlab-ce-zh   latest              b8165a7e3d68        3 months ago        1.39 GB
$ docker run --detach \
--hostname 192.168.1.8 \
--publish 8082:8082 --name gitlab9 \
--restart always \
--volume /home/gitlab:/var/opt/gitlab/git-data \
docker.io/twang2218/gitlab-ce-zh
$ docker ps

这里有一点要说明，端口映射，写的是8082到8082，就是说访问物理主机（192.168.1.8）的8082端口，相当于访问docker主机的8082端口。
但是GitLab默认的服务端口是80，要下入docker主机，改一下配置。

# 进入docker主机的ssh
$ docker exec -it gitlab9 /bin/bash

# 修改 /etc/gitlab/gitlab.rb
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@192:/# vim /etc/gitlab/gitlab.rb

#修改项目
external_url 'http://192.168.1.8:8082'

应用配置更新

gitlab-ctl reconfigure

雷点：直接重启GitLab服务，配置是不会更新的

此时，访问 http://192.168.1.8:8082，基本是OK的了。更新密码，创建项目之流，请君细测。

.gitlab-ci.yml

资料显示，GitLab8之后的版本，默认集成，并启用了GitLabCI，所以无需额外的任何配置。还是亲儿子营养多。
唯一的要求，就是你的项目代码里，必须有一个叫.gitlab-ci.yml的文件。使用GitLab管理后台，可以添加文件，添加时可以选择对应的模板文件，还是很贴心的。有如下图示：

.gitlab-ci.yml文件

文件大概的内容，就是一堆任务，包构建命令（能够把项目需要的环境构建出来，以便运行测试）测试命令，及其它你想执行的命令。
这里直接使用Laravel模板。然后需要针对自己的系统，对脚本微调：

1. apt-get替换成yum。因为我的目标机是centos7
2. 删除docker相关的内容。因为我的目标操作机没有安装docker，是一个台空白机
3. 将 https 替换成 http
4. 增加tags laravel，（很重要）增加完如下

test:
  # 下两行 很重要
  tags:
    - laravel
  script:

  # 进入后台项目目录
  - cd backend

  # run laravel tests
  - php vendor/bin/phpunit --coverage-text --colors=never 

脚本的任何错误，将造成任务运行失败

GitLab管理端，也可以看到此文件的语法检查

语法检查

CI Runner 安装 注册

先说一下大致流程：
1，安装runner
2，runner注册到 GitLab
3，当代码提交后，GitLab根据 .yml的配置，通知runner，起来，干活啦
4，runner收到任务，开始执行作业
5，GitLab接收并显示 runner 的运行结果

CI Runner的安装，依然使用Docker的方式

GitLab Runner 官方安装指南

无脑执行

$ docker pull gitlab/gitlab-runner:latest
$ docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

下面开始实施注册

1，首先需要在GitLab的后台，找到接收runner注册的页面，如下图指引：

设置--流水线

简单一点，我们搞一个特定的Runners，页面内会提供注册需要的url和密钥

2，执行注册命令
需要进入运行runner的docker主机，执行相关命令，过程如下：

# 进入docker主机的shell
$ docker exec -it gitlab-runner  /bin/bash
# 注册命令
root@94652dec6e02:/# gitlab-ci-multi-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://192.168.1.8:8082/
Please enter the gitlab-ci token for this runner:
zQRBTAAmh1Zc9BxU6G61
Please enter the gitlab-ci description for this runner:
[94652dec6e02]: just for test
Please enter the gitlab-ci tags for this runner (comma separated):
laravel
Whether to run untagged builds [true/false]:
[false]:
Whether to lock the Runner to current project [true/false]:
[true]:
Registering runner... succeeded                     runner=zQRBTAAm
Please enter the executor: docker-ssh+machine, kubernetes, docker, docker-ssh, shell, ssh, parallels, virtualbox, docker+machine:
ssh
Please enter the SSH server address (e.g. my.server.com):
192.168.1.4
Please enter the SSH server port (e.g. 22):
Please enter the SSH user (e.g. root):
xx
Please enter the SSH password (e.g. docker.io):
xx
Please enter path to SSH identity file (e.g. /home/user/.ssh/id_rsa):

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

其中的 tags 非常重要。 要和 .yml文件中的tags一致，否则会出来诸如“未找到有效的Runner”等错误提示，使流水线作业搁置

可以检查本地注册情况

# gitlab-runner list
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
first test                                          Executor=ssh Token=e23c4a3320a90c3e81074de0f87fdc URL=http://192.168.1.8:8082/
just for test                                       Executor=ssh Token=7ff71f37a5c9b108dbcb2234b574f2 URL=http://192.168.1.8:8082/

然后不要忘记，要启动runner服务

# gitlab-runner start

这里我选择了ssh的方式。此方式相当于给runner找一个『肉机』去跑项目的集成测试代码。其它方式待研究

同时，注册成功之后，GitLab管理后台，也可以看到注册信息

image.png

测试

文行致此，已万事俱备
push你的代码至版本库，GitLabCI即开始工作，如果你想看到绿色的成功图标，根据提示一步一步调试你的 .yml脚本吧

全是失败

文章写的比较仓促，主要用以记录一次CI之旅。如有运行不通，请与交流

比持续集成更重要的，是你首先要在你的项目里写好各类测试，提高测试的覆盖率，写好从源码到可运行测试的构建脚本，然后再寻求可自动化的方法

更新

本机：Ubuntu16.04
本机通过 Shell 运行：/opt/ » ./gitlab-runner-linux-amd64 run
runner register 信息：executor docker
关键信息：使用本机的 docker 服务，运行 [runner executor doctor]
配置如下图：cat ~/.gitlab-runner/config.toml

image.png

再次强调：编写可测试代码

参考博文
使用Gitlab-Runner Docker 构建 node 项目
Docker搭建自己的Gitlab CI Runner
使用docker运行gitlab服务
GitLab-CI 从安装到差点放弃