如何在 Ubuntu 20.04 上设置 GitLab 持续集成 (CI) 流水线

每个开发人员都明白版本控制对软件开发生命周期有多么至关重要。它允许多个人同时在一个项目上工作，每个人都维护自己的代码副本，并选择何时与团队的其他成员共享。为了实现这一点，开发人员利用了 Git 仓库来帮助进行版本控制。 GitLab 是一个基于 Web 的 Git 仓库，它不仅仅是一个版本控制工具。它还提供了 DevOps 工具、问题跟踪、持续集成和部署。

GitLab 提供了三个选项供您选择：GitLab 社区版 (CE)、GitLab 企业版 (EE) 和 GitLab SaaS。 GitLab CE 和 GitLab EE 是自托管解决方案。这意味着您可以自己下载、安装和管理 GitLab 实例。GitLab SaaS 由 GitLab Inc. 托管。因此，您无需担心安装任何东西即可使用它。您只需要 创建一个 GitLab 帐户 并开始使用。

在本教程中， 我们将向您展示如何使用 GitLab CI 设置持续集成管道，以监控您的仓库中的更改并运行自动化测试来验证新代码。我们将首先设置一个 Git 仓库来托管代码。然后，我们将配置一个 CI 流程来监控对仓库的提交，并启动一个 CI runner 在隔离的 Docker 容器中运行测试。

前提条件

首先，您需要一台运行 GitLab 版本控制软件的服务器。GitLab 自托管和 SaaS 都可以运行自动化测试。但是，在免费的 SaaS 选项中，您的测试在时间和资源方面存在一些限制。如果您使用的是自托管选项，您将拥有更多的自由，因为您可以为您的 GitLab 实例分配任意多的资源。请按照我们关于 使用 GitLab 托管您自己的 Git 仓库 的教程来学习如何设置您自己的 GitLab 实例。

您将需要至少一台服务器用作 GitLab CI runner。但是，如果您愿意，也可以拥有更多服务器。如果您设置了自托管的 GitLab 实例，您可以使用同一台服务器，但我们更倾向于为 CI runner 设置一台不同的服务器。这篇关于 如何设置您的 Ubuntu 服务器 的教程是一个很好的开始。

您需要在 GitLab CI runner 服务器上安装 Docker，以便在 Docker 容器中隔离测试环境。我们有一篇关于 如何在 Ubuntu 上安装和操作 Docker 的教程可以帮助您完成此要求。

现在我们已经准备好了所需的一切，让我们开始吧！

步骤 1：在 GitLab 实例上创建项目

我们将首先在 GitLab 上创建一个项目仓库。本教程将基于一个 Node.js 应用程序。由于我们不想从头开始创建项目文件，GitLab 提供了一个从其他版本控制仓库导入项目的工具，我们将利用该工具。我们导入的应用程序是一个简单的“hello world”应用，该应用基于 Express.js – 一个用于 Node.js 应用程序的极简 Web 框架。我们将使用 Mocha 和 Chai – 这些是用于单元测试的 JavaScript 框架。Mocha 支持异步测试、测试覆盖率报告，并可与其他断言库配合使用。Chai 是一个断言库。它可以与任何测试框架配合使用，在我们的案例中，我们将把 Mocha 与 Chai 配合使用。

现在您已经了解了我们项目的基本信息，请登录您的 GitLab 实例（无论是自托管还是 SaaS），点击 “加号” 图标，然后选择“新建项目”。或者，如果您滚动到帐户主页的顶部，可以点击“新建项目”按钮：

在新建项目页面上，点击 导入项目 选项卡：

接下来，在打开的页面中，点击 通过 URL 导入仓库 按钮：

虽然有 GitHub 导入选项，但我们不打算使用它，因为它需要个人访问令牌（Personal access token）。由于我们使用的是公共仓库，因此不需要设置个人访问令牌，直接使用 URL 导入非常简单。

之后，复制以下 URL 并将其粘贴到 Git Repository URL 字段中：

它应该看起来像这样：

将存储库保留为 Private 并在完成后点击 Create project 按钮。等待几秒钟，让项目从 GitHub 导入，它就会出现在您的 GitLab 存储库中。GitLab 导入的项目将具有与 GitHub 存储库项目相同的详细信息。

步骤 2：分析 .gitlab-ci.yml 文件

GitLab CI 会扫描 GitLab 上的每个存储库，以寻找名为 .gitlab-ci.yml 的文件，以了解它应该如何运行自动化测试。在我们刚刚导入的存储库中，您可以在项目文件中看到一个 .gitlab-ci.yml 文件。关于 GitLab CI yml 的更多信息，请参阅其官方的 .gitlab-ci.yml 文件关键字参考文档.

在 GitLab 存储库界面中，点击 .gitlab-ci.yml 文件以在浏览器页面中打开它。它应该看起来像这样：

请注意行缩进。该文件遵循严格的 GitLab CI YAML 配置语法，以在特定条件下按指定顺序定义要执行的各种操作。为了确保您的配置文件正确，GitLab 提供了一个用于验证的测试工具。在您的 GitLab 实例中，在您的项目存储库中，您可以访问 CI lint 界面来验证您的 .gitlab-ci.yml。点击左侧导航菜单上的 CI/CD，然后点击出现的页面中的 CI lint 按钮：

下面将讨论配置文件中的指令。

• 基础 Docker 镜像

配置文件中的第一行声明了应该用于运行测试的 Docker 镜像。由于我们正在构建 Node.js 应用程序，因此我们将使用最新的 Node.js 镜像：

• 阶段

然后，我们定义希望持续集成测试通过的不同阶段。我们只有两个阶段：

在定义阶段名称时，像 build 或 test 这样的名称是随机选择的 – 您可以选择任何您喜欢的名称。但是，您必须正确排列阶段의 顺序，因为这决定了执行流程。在我们的例子中，build 阶段中的作业会在 test 阶段中的作业之前执行。GitLab Runner 将并行执行同一阶段中的作业，并等待所有作业完成后才开始执行下一阶段中的作业。

• 缓存

其中包含 cache 定义，以指定在作业运行之间将被缓存或保存以供以后使用的文件和目录：

定义缓存有助于最大限度地减少运行依赖于在运行之间不太可能发生变化的资源的作业所需的时间。我们指定要缓存的 node_modules 目录。这是 npm 安装项目依赖项的目录。

• 作业

我们在配置中有两个作业：

• install_dependencies

在命名作业时，您可以自由选择任何名称。但是，建议使用具有描述性的名称，因为它们会显示在 GitLab UI 中 – 这在调试期间会很有帮助。您会发现网络上的大多数配置都结合了 npm install 与测试阶段的命令。我们只是将它们分开，以帮助演示作业是如何交互的，因为这是一个非常小的项目。 stage 指令将此作业标记为 build – 它在 build 阶段.

The script 指令指定了在此作业执行中运行的命令。您可以通过在 script 块中添加行来指定多个命令。当然，您需要注意正确的缩进，并记住脚本应该执行的顺序。

The artifacts 指令指定要在阶段之间保存和共享的文件或目录路径。再次提醒，正确安排阶段顺序对于确保其他文件拥有执行所需的内容至关重要。 npm install 命令将安装依赖项到 node_modules 目录中。通过在 artifacts 中声明它，我们使其可用于后续阶段执行的作业。如果您想下载这些文件，也可以在 GitLab UI 中找到它们。

• test_with_mocha

此作业在 test 阶段运行。由于此作业在 build 阶段运行之后运行，因此在 build 阶段声明的制品（即我们应用程序的依赖项）将可用于 test 阶段。script 块指定了用于运行测试的 npm 命令。我们首先启动应用程序，然后针对该应用程序运行测试。运行这些命令会触发在 package.json 脚本块部分中指定的命令：
至此，您应该对 .gitlab-ci.yml 文件有了基本的了解。我们说基本，是因为这只是一个静态的 hello world 应用程序。接下来，让我们看看如何触发新的 CI 运行。

步骤 3：触发 GitLab CI 运行

您会很高兴地知道，一旦您的仓库中有了 .gitlab-ci.yml 文件，您推送给它的任何新提交都将触发新的持续集成运行。对于自托管的 GitLab 实例，如果您尚未配置 GitLab runner，CI 运行将被设置为“pending”（挂起）。

GitLab SaaS 为用户提供了一些共享 runner，它们可以自动接收并执行作业。这只有在共享 runner 空闲且您没有超出配额的情况下才有可能。在 GitLab SaaS 中，您可以通过转到项目的 shared runners 来选择是否让您的仓库使用它，方法是转到项目的 Settings > CI / CD 页面，如下面的屏幕截图所示。在此页面中，您还将找到有关 GitLab runner 安装说明的信息，我们将在下一步中对此进行深入探讨：

现在，让我们进行一个小的更改来触发 CI 运行。导航回您的 node_pipeline GitLab 项目仓库：

单击上面突出显示的 README.md 文件以查看它：

单击 “Edit” 按钮以在浏览器中打开文件进行编辑，并添加一些文本：

添加一些文本后，向下滚动并单击 Commit changes 按钮以保存更改。您可以根据需要修改提交信息。当流水线运行时，它将作为标题显示在 GitLab UI 中。我们将其保留为 Update README.md ，因为它非常具有描述性：

提交更改后，返回主项目页面。您会注意到最近的提交旁边有一个小的 paused icon 。如果您将鼠标悬停在该图标上，它将显示：“Pipeline:pending”：

这意味着 CI 运行已被触发。但是，测试尚未运行。在左侧的导航菜单中，单击 CI/CD, 然后选择 Pipelines。 这将打开一个页面，显示有关流水线的更多详细信息。您可以看到 CI 处于挂起状态并被标记为卡住（stuck）：

要获取有关运行的更多详细信息，请单击 pending 状态。您将看到下面的视图，其中显示了运行的不同阶段以及链接到每个阶段的单个作业：

您还可以单击单个作业以查看其更详细的信息，例如导致延迟的原因。在运行失败的情况下，您可以在此处查看导致作业失败的原因：

该消息表明作业已卡住，因为您尚未配置任何可以执行此作业的活动 runner。我们将在下一步中进行配置。当您使 runner 可用时，作业将自动开始执行。当作业执行时，您将在此界面上看到输出，以及在作业运行时生成的其他可下载制品。

第 4 步：设置 GitLab CI Runner 服务

现在是时候使用我们在“前提条件”部分中声明的第二台服务器了。我们将在该服务器上安装并设置 GitLab runner 服务。您可以部署该服务，以便为 GitLab 上的不同项目运行多个 runner 实例。

您可以选择在托管自托管 GitLab 实例的同一台服务器上部署 runner。但是，为了确保实例不受资源限制，最好设置一个独立的 CI runner 实例。无论您选择哪种配置，都必须安装 Docker以隔离测试环境。

安装 GitLab CI runner 的过程与安装 GitLab 自托管实例的过程类似。我们首先使用以下命令下载一个脚本，将官方 GitLab 仓库添加到 apt 源中：

出现提示时提供您的 root 密码。接下来，您现在可以运行命令来安装最新的 GitLab CI runner：

上述命令将安装并注册一个 runner 服务，供您的项目使用。

第 5 步：获取注册令牌并关联 GitLab Runner

要设置 GitLab CI runner 以开始接收作业，您需要一个 GitLab runner 令牌。runner 需要使用它来向您的 GitLab 服务器实例进行身份验证。根据您希望如何使用 runner，有两种类型的令牌：项目特定和共享 runner。

项目特定 runner适用于您对 runner 有独特需求的情况。例如，如果您的gitlab-ci.yml中包含带有独特令牌的部署定义，那么可能建议使用特定的 runner 来正确验证到部署环境中。另一个考虑因素是您的持续集成阶段是否包含资源密集型过程。如果是这样，选择项目特定 runner 将是理想的选择。请注意，项目特定 runner 不接受来自其他项目的作业。

共享 runner是通用的，可以被多个项目使用。托管在GitLab Inc上的 GitLab SaaS 实例具有一些共享 runner，它们将自动接收您的流水线，正如在第三步中所解释的那样。Runner 根据一种算法从您的配置中获取作业，该算法会考虑每个项目当前正在执行的作业数量。共享 runner 比特定 runner 更灵活。它可以从 GitLab 实例的管理员帐户进行配置。让我们来看看如何获取这两种 runner 的令牌。

• 注册项目特定 Runner

要注册项目特定 runner，请在您的 GitLab 实例或 GitLab SaaS 帐户中打开您的项目。在左侧的导航菜单中，单击设置项并选择CI/CD选项：

之后，向下滚动到Runner部分，然后单击按钮展开该部分：

左侧解释了如何注册项目特定 runner。这是 GitLab SaaS 实例的视图。您也可以使用 Kubernetes 配置自动 runner，但本教程中我们将使用手动 runner：

接下来，您需要关注为您提供该项目令牌（token）的区域。对于自托管的 GitLab 实例，该 URL 将显示运行您的 GitLab 实例的服务器域名：

您可以通过切换右侧区域下方的开关来选择禁用此项目的共享 runner：共享 Runner。 然后，将显示的注册令牌复制到您的记事本中，因为我们稍后会用到它。

• 注册共享 Runner

要注册共享 runner，您需要以管理员身份登录您的自托管 GitLab 实例。要访问管理面板，请点击顶部导航菜单中的 扳手 图标：

在 管理面板 中，点击左侧菜单 Runners 区域中的 概览。这将打开一个包含 共享 Runner 配置说明的页面：

复制右侧显示的注册令牌，位于 手动设置共享 Runner 下方。您将在下一步中使用该令牌来注册 runner。

• 将 GitLab CI Runner 与 GitLab 实例关联

在此步骤中，您将把 GitLab 实例与 CI runner 关联起来。重新登录您在第四步之中安装了 GitLab runner 服务的服务器。要开始 runner 注册过程，请在终端中输入以下命令：

该命令会向您提出一系列问题：

• 输入 GitLab 实例 URL（例如，https://gitlab.com/）：

使用 https:// 来指定 SSL 并提供您的 GitLab 实例域名。

• 输入注册令牌：

提供您的注册令牌。在这里，您将选择希望此 runner 是项目特定的还是共享的。对于这两个选项，您只能提供之前复制的其中一个令牌。

• 输入 runner 的描述：

为您的 CI runner 选择一个描述性名称，因为它将显示在 GitLab 实例界面上。

• 输入执行器（executor）：custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes：

这里为您提供了选择运行作业的执行器的选项。输入 Docker.

• 输入 runner 的标签（逗号分隔）：

这是可选的。您可以输入任何标签名称，例如此 runner 包含的依赖项。您现在可以将其留空。

• 输入默认 Docker 镜像（例如，ruby:2.6）：

在这里，您需要指定一个默认的通用镜像，用于在 gitlab-ci.yml 文件未指定镜像时运行作业。输入 alpine:latest，因为它是一个体积小、通用且安全的镜像。按回车键，runner 将自动注册并启动：

要查看当前可用的 runner 列表，请输入以下命令：

步骤 6：确认 CI Runner 已成功关联到 GitLab

接下来，返回浏览器并访问 GitLab 实例中的项目页面。根据您注册 runner 以来过去的分钟数，您可能会看到作业当前正在运行：

或者它可能已经完成：

之后，导航到 流水线 (Pipelines) 页面，可以通过左侧菜单 CI/CD > Pipelines，或者通过点击 running, passed, 或 failed 图标（如果流水线遇到错误）来查看 CI 运行的状态。在这里我们可以看到其中一个阶段（构建阶段）已经通过，而另一个仍在运行：

在表格中，阶段 (Stages) 表头下方，点击其中一个阶段图标以查看关联的作业：

然后，在弹出窗口中点击一个作业以查看详情：

作业已运行，您可以在 npm 命令安装依赖项时看到进度。在右侧，您可以查看其他相关信息。您可以选择下载该作业的产物（artifacts）。您还可以在下拉菜单中切换不同阶段以查看其他作业。

在这里，您可以查看当您在测试阶段选择该作业时显示的测试用例：

可用的 Runner

在左侧菜单中，如果您点击 Settings > CI/CD，并展开 Runners 部分，您应该会看到刚刚注册的 runner。根据您指定的是项目特定 token 还是共享 token，runner 将分别显示在相应的区域中。

在这里，您可以看到我们注册了一个项目特定的 token。该 runner 显示在 特定 Runner:

总结

在本教程中，您学习了如何使用 GitLab CI 自动执行测试。我们首先在 GitLab 上设置了一个 Node.js 应用项目。该项目包含一些测试用例和一个 gitlab-ci.yml。我们了解到 GitLab 使用 gitlab-ci.yml 文件来确定触发时要执行的操作。一个 gitlab-ci.yml 文件只是一个配置文件，其中包含构建和测试应用程序的指令，以 YAML 格式编写，以便 GitLab CI runner 能够理解。

我们还成功在独立的宿主机上设置了 GitLab CI runner。我们对其进行了注册，以便在有触发时从我们的 GitLab 实例中获取作业。虽然这是一个简单的项目，但您可以基于这些信息为复杂的项目设置流水线。将项目添加到 GitLab 以及链接 GitLab CI runner 的步骤是相同的。改变的只是 gitlab-ci.yml 文件中的指令和阶段。

祝您计算愉快！