Preface
自从「iOS 项目持续集成实践（一）」发布之后，发生了很多事情，原本计划持续更新的系列文章也因此没有更新。这次我将重拾该系列，本文的围绕核心为「使用 GitLab Runner 搭建 CI」。
What
在开始之前，我们首先要明确使用 CI 要解决哪些具体问题，这次我们先来关注代码到主仓库的过程。
在工程师开发完新 Feature 或者修复好 Bug 时，需要将代码提交到相应的仓库的某个分支，大多数团队会在代码合并（Merge）之前，强制 Code Review（代码审查）并给出 Approve（确认）或者 Comment（评论）。然而在一个团队中，每天都可能会有数十个合并请求，这样的 Code Review 很难强制约束到每个审查代码的人都能够「人眼编译」、并保证代码是合理的实践。
那么我们将希望 CI 能够替工程师完成一些固定化的检查和操作，比如单元测试、资源压缩，并在这些检查和操作都成功的前提下，再进行关注业务的 Code Review 将会高效很多。当然，CI 并不能替代 Code Review，但利用 CI 可以减轻 Code Review 的工作量，并显著提升代码和工程质量。
我们目前使用的代码托管平台是公司内部搭建的 GitLab EE，因此为了更加便捷地集成，我们选择了 GitLab Runner 作为 CI 脚本执行者，下面我们将一步步搭建、配置。
How
环境搭建
由于 Xcode 目前只能运行在 macOS 上，所以我们选择的 CI 机器是一台 Mac Pro，并重装了目前最新版本的 macOS，从零开始。关于这台 Mac Pro 的信息，可以参考下表：
| Mac Pro | Info |
|---|---|
| Version | Late 2013 |
| Processor | 3.5 GHz 6-Core Intel Xeon E5 |
| Memory | 16 GB 1866 MHz DDR3 |
| Storage | 256 GB Flash Storage |
| System | macOS 10.14.4 |
iTerm + fish (Optional)
安装 iTerm 替代系统自带的 Terminal；以及 fish shell 替代系统自带的 bash shell，fish shell 是我最近开始替代 zsh 的新选择，关于其配置可以参考 EZConfigs - shell - fish。
⚠️：该步骤并不会影响后续设置及结果，仅为可选。
安装 Xcode
由于我们目前的 iOS 项目是 Swift + Obj-C 混编，虽然 Swift 5.0 已经 Release，但目前还没有来得及更新，因此我们这里安装的仍然是 Xcode 10.1。为了同时兼容 Xcode 后续版本，我们可以将 Xcode 的名称改为「Xcode-10.1」，这样即可和其他 Xcode 版本共存，并使用 xcode-select 进行切换。
⚠️：Xcode 第一次安装成功后，需要手动打开，它将自动安装 Command Line Tools。待安装完毕后，在 iTerm/Terminal 执行 xcode-select -p 尝试打印当前的 Xcode Command Line Tools 路径。如果未正确输出，可以使用 sudo xcode-select -s /Applications/Xcode-10.1.app 手动更改为我们安装的路径。
Homebrew
Homebrew 是 macOS 上必备的软件包管理工具。为了统一管理各种软件，我都会尽量使用 Homebrew。在 iTerm/Terminal 中执行以下命令来安装：
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
⚠️：安装期间可能需要输入系统密码。
安装 GitLab Runner
使用 Homebrew 安装 GitLab Runner：
brew install gitlab-runner
配置 Runner
安装好 GitLab Runner 下面就可以来注册、配置了。
注册 Runner
sudo gitlab-runner register
依次输入操作系统账户密码；GitLab URL 和 GitLab CI Token，这两个内容可以在 GitLab 网页中找到，打开 GitLab 项目，左侧「Settings」-「CI/CD」-「Runners settings」-「Expand」-「Specific Runners」下方找到（可参考下图）：
接着需要填写描述信息，方便在 Runner 页面查看；Tag，即标签，多个标签使用 , 分隔，标签可以在后续指定某个或某些确定的 Runner，因此我这里截取了 Mac Pro 序列号的后四位作为唯一标志；执行器（Executor），代表了运行脚本的执行者，由于 iOS 项目比较特殊，无法使用 Docker 等 Linux 系统的容器，所以这里选择 shell，后续我们将使用 shell 命令（xcodebuild）来执行 Xcode。
当我们完成注册后，就可以在 GitLab 网页中查看到我们刚刚配置的 Runner：
Tips
我们可以注意到右侧（箭头）的「Shared Runners」，即共享 Runner。但由于 iOS 项目特殊，必须依赖 macOS 中的工具链，所以这些 Runner 基本上都无法满足我们的需要，可以将该选项关闭，否则在不指定 Tag 时可能会随机分配到错误环境的 Runner，从而引发错误。
