本文仅针对 macOS 和 Linux 平台，讲解如何注册 GitLab-Runner。Windows 平台不包含在本文介绍范围内。

GitLab-CI 系列文章目前有三篇，主要讲解 GitLab-CI 的环境搭建与配置。本文为该系列的第二篇。

目录：

Runner 的分类

Runner 按照适用范围分为以下三类：

  1. 项目 Runner：仅某个项目可以使用该 Runner，其他项目不可使用。
  2. 群组 Runner：某个群组下的项目都可以使用该 Runner，其他群组下的项目不可使用。
  3. 共享 Runner：整个 GitLab 系统中的所有项目都可以使用该 Runner。

注册 Runner

前期准备

  1. 打开并登录 GitLab。
  2. 思考你需要注册哪种 Runner。
    1. 如果你需要注册第一种 “项目 Runner”，那么你需要打开某个具体的 git 项目。
    2. 如果你需要注册第二种 “群组 Runner”，那么你需要打开某个具体的群组。
  3. 找到左侧导航栏最下方的设置按钮，依次选择 “设置（Settings） -> CI/CD -> Runners”。
  4. 点击 Runner 右侧的 “展开” 按钮。
  5. 在展开内容的左侧，找到 “Set up a specific Runner manually” 中的内容。

后续将使用 “Set up a specific Runner manually” 中的内容注册 Runner。

注册

在终端中执行如下命令，开始注册流程：

注意：
如果是在 Linux 平台上注册，请使用 sudo 执行 register 命令，macOS 则直接执行下方命令即可。

gitlab-runner register

针对顶部黄色WARNING警告的说明请参考：顶部黄色WARNING警告。

1. 输入 GitLab URL

执行完命令后，首先要求输入 GitLab 的 url。填入你们 GitLab 的地址即可。

细心的你可能会注意到，“Set up a specific Runner manually” 中的 url 是 http，这里写的却是 https。
其实正确的应该是 https。如果你使用 http 进行注册，那么进行到最后你将收到 “认证失败” 的错误。

2. 输入 Token

这里的 token 来自 “前期准备” 一节中 “Set up a specific Runner manually” 里显示的 Token。
复制该 token 并贴入这里，按回车进入下一步。

3. 给 Runner 起一个名字

该值后续可进行修改，详见 配置 GitLab-Runner

第三步要求输入一个 description 描述，其实理解为 Runner 的名字会更好一点。
一般使用英文，例如 “sever_xxx_ios_project_spare”。

4. 设置 Runner 的标签

该值后续可进行修改，详见 配置 GitLab-Runner

标签列表（tag）决定着 Runner 可以执行哪些任务（job）。
在这一步您可以设置多个标签，之间使用 , 号分割即可。
一个清晰、简短并且可以表达 Runner 职责的标签名才是一个好的标签名。

针对 tag 的简单说明

上文有提到，Runner 首先会被项目、群组等范围限制着。

但是这样还不够，在下面这个现实场景中，就会有很多问题：
假设现在有一个“项目Runner”：

  • 该 git 项目设置了多个CI/CD任务
  • 该 git 项目内还注册了多个 Runner，甚至还有继承自群组的 Runner
    此时如果你有特殊需求，需要任务A必须执行在RunnerA上，该如何做？

这时我们就可以通过 “标签” 来做到这点，只需要确保RunnerA的标签包含任务A的标签即可。
只有当 Runner 的标签列表包含将要执行的任务的标签时，才会选择该 Runner 去执行这个任务。否则即使该 Runer 处于空闲状态，也不会被使用。

5. 无视这一步

直接按回车即可。

6. 选择执行器

当你输入正确的 url 和 token，那么你将最后一步：选择 Runner 的执行器：

在这一步输入你想选择的执行器的名称，输入回车即可完成 Runner 的注册。
有关执行器的详细说明，请参考 GitLab 的官方文档。这里重点说一下比较常用的两种执行器：shell 和 docker。

shell

shell 执行器有以下几个特点：

  • 当前任务在 本机的shell环境 下执行，意味着当前任务生成的文件将直接生成在本机路径内，不需要做任何外的配置，任务就可以访问本机中任意文件。
  • 每个任务和每个任务之间没有隔离，意味着当前任务生成的文件，不需要任何额外配置，就能够被下个任务直接读取使用。

shell 执行器一般用于执行纯 shell 命令、脚本，同时对任务之间的隔离不敏感的任务。
iOS、macOS App 打包必须选择 shell 执行器，无法使用 docker 执行。

docker

简单地、按照本文作者的个人理解，解释一下 docker 是什么：
docker 技术即容器技术，基于 docker 可以快速地配置好用户所需的开发环境，同时基于 docker，可以实现容器与容器之间的隔离。
当我们选择 docker 执行器后，下一步会让我们填写一个默认的 docker 镜像名称，该名称后续可更改。
Android 打包、上传 bugly 等操作均可使用 docker 执行器执行。

总结

  • iOS、macOS App 打包只能选择 shell。
  • 不需要考虑任务与任务之间互相隔离的、轻量化的任务可以选择 shell。
  • 需要复杂的开发环境，任务与任务之间需要互相隔离，或者较为繁杂的任务可以选择 docker。

顶部黄色WARNING警告

首先，如果是在 macOS 环境下，那么无视该警告即可；
如果是在 Linux 环境下，则是因为执行 gitlab-runner register 命令时没有添加 sudo 导致的，中断当前流程，重新执行 sudo gitlab-runner register 即可。

通过上文我们已经了解到，iOS 打包必须在 shell 环境下执行，打包过程中使用当前用户申请去执行相关 gitlab-runner 命令，所以在注册 runner 时，无法使用 sudo 执行。

GitLab-Runner 没有对此进行额外的判断，所以只要不加 sudo，就是 user-mode，就会输出该警告。