GitLab-CI(二):注册 GitLab-Runner
本文仅针对 macOS 和 Linux 平台,讲解如何注册 GitLab-Runner。Windows 平台不包含在本文介绍范围内。
GitLab-CI 系列文章目前有三篇,主要讲解 GitLab-CI 的环境搭建与配置。本文为该系列的第二篇。
目录:
Runner 的分类
Runner 按照适用范围分为以下三类:
- 项目 Runner:仅某个项目可以使用该 Runner,其他项目不可使用。
- 群组 Runner:某个群组下的项目都可以使用该 Runner,其他群组下的项目不可使用。
- 共享 Runner:整个 GitLab 系统中的所有项目都可以使用该 Runner。
注册 Runner
前期准备
- 打开并登录 GitLab。
- 思考你需要注册哪种 Runner。
- 如果你需要注册第一种 “项目 Runner”,那么你需要打开某个具体的 git 项目。
- 如果你需要注册第二种 “群组 Runner”,那么你需要打开某个具体的群组。
- 找到左侧导航栏最下方的设置按钮,依次选择 “设置(Settings) -> CI/CD -> Runners”。
- 点击 Runner 右侧的 “展开” 按钮。
- 在展开内容的左侧,找到 “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
,就会输出该警告。