本文仅针对 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 的官方文档。这里重点说一下比较常用的两种执行器:shelldocker

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,就会输出该警告。