介绍
GitLab 社区版是一个自托管的 Git 存储库提供程序，具有帮助项目管理和软件开发的附加功能。 GitLab 提供的最有价值的功能之一是内置的持续集成和交付工具，称为 GitLab CI。
在本指南中，我们将演示如何设置 GitLab CI 来监控存储库的更改并运行自动化测试来验证新代码。 我们将从一个正在运行的 GitLab 安装开始，我们将为基本的 Node.js 应用程序复制一个示例存储库。 配置我们的 CI 流程后，当一个新的提交被推送到存储库时，GitLab 将使用 CI 运行器针对隔离的 Docker 容器中的代码执行测试套件。
先决条件
在我们开始之前，您需要设置一个初始环境。 我们需要配置一个安全的 GitLab 服务器来存储我们的代码并管理我们的 CI/CD 流程。 此外，我们需要一个地方来运行自动化测试。 这可以是安装 GitLab 的同一台服务器，也可以是单独的主机。 以下部分更详细地介绍了这些要求。
使用 SSL 保护的 GitLab 服务器
要存储源代码并配置我们的 CI/CD 任务，我们需要在 Ubuntu 16.04 服务器上安装一个 GitLab 实例。 GitLab 目前推荐至少有 2 个 CPU 核心 和 4GB 内存 的服务器。 为了保护您的代码不被暴露或篡改，GitLab 实例将使用 Let's Encrypt 使用 SSL 进行保护。 您的服务器需要有一个与之关联的域名或子域才能完成此步骤。
您可以使用以下教程完成这些要求：
- 使用 Ubuntu 16.04 进行初始服务器设置：创建
sudo用户并配置基本防火墙 - 如何在 Ubuntu 16.04 上安装和配置 GitLab：在服务器上安装 GitLab 并使用 Let's Encrypt TLS/SSL 证书保护它
我们将演示如何在项目之间共享 CI/CD 运行器（运行自动化测试的组件）以及如何将它们锁定到单个项目。 如果您希望在项目之间共享 CI 运行器，我们强烈建议您限制或禁用公共注册。 如果您在安装过程中没有修改设置，请返回并按照 GitLab 安装文章中关于限制或禁用注册 的可选步骤操作，以防止外部各方滥用。
一台或多台服务器用作 GitLab CI 运行器
GitLab CI Runners 是检查代码并运行自动化测试以验证新更改的服务器。 为了隔离测试环境，我们将在 Docker 容器中运行所有自动化测试。 为此，我们需要在将运行测试的一个或多个服务器上安装 Docker。
此步骤可以在 GitLab 服务器或不同的 Ubuntu 16.04 服务器上完成，以提供额外的隔离并避免资源争用。 以下教程将在您希望用于运行测试的主机上安装 Docker：
- 使用 Ubuntu 16.04 进行初始服务器设置：创建
sudo用户并配置基本防火墙（如果您在 GitLab 服务器上设置 CI 运行器，则无需再次完成此操作） - 如何在Ubuntu 16.04上安装和使用Docker：按照步骤1和2在服务器上安装Docker
当您准备好开始时，请继续阅读本指南。
从 GitHub 复制示例存储库
首先，我们将在 GitLab 中创建一个包含示例 Node.js 应用程序的新项目。 我们将 直接从 GitHub 导入原始存储库，这样我们就不必手动上传了。
登录GitLab，点击右上角的【X30X】加号【X43X】，选择【X86X】新建项目【X101X】添加新项目：
在新建项目页面，点击【X38X】导入项目【X56X】选项卡：
接下来，单击 Repo by URL 按钮。 尽管有 GitHub 导入选项，但它需要个人访问令牌并用于导入存储库和其他信息。 我们只对代码和 Git 历史感兴趣，因此通过 URL 导入更容易。
在 Git 存储库 URL 字段中，输入以下 GitHub 存储库 URL：
https://github.com/do-community/hello_hapi.git
它应该如下所示：
由于这是一个演示，最好将存储库标记为 Private。 完成后，单击创建项目。
新项目将基于从 GitHub 导入的存储库创建。
了解 .gitlab-ci.yml 文件
GitLab CI 在每个存储库中查找一个名为 .gitlab-ci.yml 的文件，以确定它应该如何测试代码。 我们导入的存储库已经为项目配置了一个 gitlab-ci.yml 文件。 您可以通过阅读.gitlab-ci.yml参考文档了解更多关于格式的信息
点击我们刚刚创建的项目的GitLab界面中的.gitlab-ci.yml文件。 CI 配置应如下所示：
.gitlab-ci.yml
image: node:latest
stages:
- build
- test
cache:
paths:
- node_modules/
install_dependencies:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
test_with_lab:
stage: test
script: npm test
该文件使用 GitLab CI YAML 配置语法 来定义应采取的操作、应执行的顺序、应在何种条件下运行以及完成每项任务所需的资源。 在编写自己的 GitLab CI 文件时，您可以通过转到 GitLab 实例中的 /ci/lint 来访问语法 linter，以验证您的文件格式是否正确。
配置文件首先声明应该用于运行测试套件的 Docker image。 由于 Hapi 是一个 Node.js 框架，我们使用的是最新的 Node.js 镜像：
image: node:latest
接下来，我们明确定义将运行的不同持续集成阶段：
stages: - build - test
您在此处选择的名称是任意的，但顺序决定了后续步骤的执行顺序。 阶段是您可以应用于单个作业的标签。 GitLab 将并行运行同一阶段的作业，并等待执行下一阶段，直到当前阶段的所有作业完成。 如果没有定义阶段，GitLab 将使用三个阶段，称为 build、test 和 deploy，并将所有作业默认分配给 test 阶段。
定义阶段后，配置包含一个 cache 定义：
cache:
paths:
- node_modules/
这指定了可以在运行或阶段之间缓存（保存以供以后使用）的文件或目录。 这有助于减少运行依赖于在运行之间可能不会改变的资源的作业所需的时间。 在这里，我们缓存了 node_modules 目录，npm 将安装它下载的依赖项。
我们的第一份工作叫做 install_dependencies：
install_dependencies:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
作业可以命名为任何名称，但由于名称将在 GitLab UI 中使用，因此描述性名称很有帮助。 通常，npm install 可以与下一个测试阶段结合，但为了更好地展示阶段之间的交互，我们将这一步提取出来运行在自己的阶段。
我们使用 stage 指令将阶段明确标记为“构建”。 接下来，我们使用 script 指令指定要运行的实际命令。 您可以通过在 script 部分中添加额外的行来包含多个命令。
artifacts 小节用于指定要在阶段之间保存和传递的文件或目录路径。 因为 npm install 命令会安装项目的依赖项，我们的下一步将需要访问下载的文件。 声明 node_modules 路径可确保下一阶段可以访问文件。 这些也可以在测试后在 GitLab UI 中查看或下载，因此这对于构建像二进制文件这样的工件也很有用。 如果您想保存舞台期间产生的所有内容，请将整个 paths 部分替换为 untracked: true。
最后，名为 test_with_lab 的第二个作业声明了将实际运行测试套件的命令：
test_with_lab: stage: test script: npm test
我们把它放在 test 阶段。 由于这是一个后期阶段，它可以访问由 build 阶段生成的工件，在我们的例子中是项目依赖项。 在这里，script 部分演示了当只有一个项目时可以使用的单行 YAML 语法。 我们也可以在上一个作业中使用相同的语法，因为只指定了一个命令。
现在您对 .gitlab-ci.yml 文件如何定义 CI/CD 任务有了基本的了解，我们可以定义一个或多个能够执行测试计划的运行器。
触发持续集成运行
由于我们的存储库包含一个 .gitlab-ci.yml 文件，因此任何新的提交都会触发新的 CI 运行。 如果没有可用的运行器，CI 运行将设置为“待定”。 在我们定义一个运行器之前，让我们触发一个 CI 运行来查看一个作业在挂起状态下的样子。 一旦跑步者可用，它将立即拿起挂起的跑步。
回到 hello_hapi GitLab 项目存储库视图，单击分支和项目名称旁边的 加号 ，然后从菜单中选择 New file：
在下一页上，在 文件名 字段中输入 dummy_file 并在主编辑窗口中输入一些文本：
完成后点击底部的Commit changes。
现在，返回主项目页面。 一个小的 paused 图标将附加到最近的提交。 如果将鼠标悬停在图标上，它将显示“Commit:pending”：
这意味着验证代码更改的测试尚未运行。
要获取更多信息，请转到页面顶部并单击 Pipelines。 您将被带到管道概览页面，您可以在其中看到 CI 运行被标记为待处理并标记为“卡住”：
注意： 右侧是 CI Lint 工具的按钮。 在这里您可以检查您编写的任何 gitlab-ci.yml 文件的语法。
从这里，您可以单击 待定 状态以获取有关运行的更多详细信息。 此视图显示了我们运行的不同阶段，以及与每个阶段关联的各个作业：
最后，单击 install_dependencies 作业。 这将为您提供有关延迟运行的具体细节：
此处，消息表明作业由于缺少运行器而被卡住。 这是意料之中的，因为我们还没有配置任何东西。 一旦运行器可用，就可以使用相同的界面查看输出。 这也是您可以下载构建期间生成的工件的位置。
现在我们知道了待处理的工作是什么样的，我们可以为我们的项目分配一个 CI 运行器来获取待处理的工作。
安装 GitLab CI Runner 服务
我们现在准备好设置一个 GitLab CI 运行器。 为此，我们需要在系统上安装 GitLab CI 运行程序包并启动 GitLab 运行程序服务。 该服务可以为不同的项目运行多个运行器实例。
如先决条件中所述，如果要确保避免资源争用，可以在托管 GitLab 实例的同一台服务器或不同服务器上完成这些步骤。 请记住，无论您选择哪个主机，都需要为我们将使用的配置安装 Docker。
安装 GitLab CI 运行器服务的过程类似于安装 GitLab 本身的过程。 我们将下载一个脚本来将 GitLab 存储库添加到我们的 apt 源列表中。 运行脚本后，我们将下载运行程序包。 然后我们可以配置它来服务我们的 GitLab 实例。
首先将最新版本的 GitLab CI 运行器存储库配置脚本下载到 /tmp 目录（这是与 GitLab 服务器使用的不同的存储库）：
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh
随意检查下载的脚本，以确保您对它将采取的操作感到满意。 您还可以在 此处找到脚本 的托管版本：
less /tmp/gl-runner.deb.sh
一旦您对脚本的安全性感到满意，请运行安装程序：
sudo bash /tmp/gl-runner.deb.sh
该脚本将设置您的服务器以使用 GitLab 维护的存储库。 这使您可以使用与其他系统包相同的包管理工具来管理 GitLab 运行程序包。 完成后，您可以使用 apt-get 继续安装：
sudo apt-get install gitlab-runner
这将在系统上安装 GitLab CI 运行程序包并启动 GitLab 运行程序服务。
设置 GitLab Runner
接下来，我们需要设置一个 GitLab CI 运行器，以便它可以开始接受工作。
为此，我们需要一个 GitLab 运行器令牌，以便运行器可以通过 GitLab 服务器进行身份验证。 我们需要的令牌类型取决于我们要如何使用这个运行器。
如果您对跑步者有特定要求，则 项目特定跑步者 很有用。 例如，如果您的 gitlab-ci.yml 文件定义了需要凭据的部署任务，则可能需要特定的运行器才能正确验证进入部署环境。 如果您的项目在 CI 过程中有资源密集型步骤，这也可能是一个好主意。 项目特定的跑步者不会接受其他项目的工作。
另一方面，shared runner 是一个通用的运行器，可以被多个项目使用。 跑步者将根据一种算法从项目中获取工作，该算法考虑了每个项目当前正在运行的工作数量。 这种类型的跑步者更灵活。 您需要使用管理员帐户登录 GitLab 以设置共享运行器。
我们将在下面演示如何获取这两种跑步者类型的跑步者令牌。 选择最适合您的方法。
收集信息以注册特定项目的跑步者
如果您希望运行器与特定项目相关联，请首先导航到 GitLab 界面中的项目页面。
在此处，单击左侧菜单中的 设置 项。 然后点击子菜单中的CI/CD项：
在此页面上，您将看到 Runners settings 部分。 单击 展开 按钮以查看更多详细信息。 在详细视图中，左侧将解释如何注册特定于项目的运行器。 复制说明第 4 步中显示的注册令牌：
如果您希望禁用此项目的任何活动共享运行器，您可以通过单击右侧的 Disable shared Runners 按钮来实现。 这是可选的。
当您准备好后，请继续学习如何使用您从该页面收集的信息来注册您的跑步者。
收集信息以注册共享跑步者
要查找注册共享跑步者所需的信息，您需要使用管理帐户登录。
首先单击顶部导航栏中的 扳手图标 以访问管理区域。 在左侧菜单的Overview部分，点击Runners，进入共享运行器配置页面：
复制页面顶部显示的注册令牌：
我们将使用这个令牌为项目注册一个 GitLab CI 运行器。
向 GitLab 服务器注册 GitLab CI Runner
现在您有了令牌，请返回安装 GitLab CI 运行器服务的服务器。
要注册新的跑步者，请输入以下命令：
sudo gitlab-runner register
您将被问到一系列问题来配置运行器：
请输入 gitlab-ci 协调器 URL（例如 https://gitlab.com/)
输入 GitLab 服务器的域名，使用 https:// 指定 SSL。 您可以选择将 /ci 附加到域的末尾，但最近的版本会自动重定向。
请输入此跑步者的 gitlab-ci 令牌
您在上一节中复制的令牌。
请输入此跑步者的 gitlab-ci 描述
这个特定跑步者的名字。 这将显示在命令行和 GitLab 界面上的运行器服务的运行器列表中。
请输入此跑步者的 gitlab-ci 标签（逗号分隔）
这些是您可以分配给跑步者的标签。 GitLab 作业可以根据这些标签表达需求，以确保它们在具有正确依赖关系的主机上运行。
在这种情况下，您可以将其留空。
是否将 Runner 锁定到当前项目 [true/false]
将运行器分配给特定项目。 它不能被其他项目使用。
此处选择“假”。
请输入执行人
跑步者用来完成工作的方法。
在这里选择“码头工人”。
请输入默认的 Docker 镜像（例如 红宝石：2.1）
当 .gitlab-ci.yml 文件不包含图像规范时，用于运行作业的默认图像。 最好在这里指定一个通用图像，并在您的 .gitlab-ci.yml 文件中定义更具体的图像，就像我们所做的那样。
我们将在此处输入“alpine:latest”作为一个小的、安全的默认值。
回答提示后，将创建一个能够运行项目的 CI/CD 任务的新运行器。
您可以通过键入以下命令查看 GitLab CI 运行器服务当前可用的运行器：
sudo gitlab-runner list
OutputListing configured runners ConfigFile=/etc/gitlab-runner/config.toml example-runner Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com
现在我们有了可用的运行器，我们可以返回 GitLab 中的项目。
在 GitLab 中查看 CI/CD 运行
返回您的 Web 浏览器，返回 GitLab 中的项目。 根据您注册跑步者以来的时间，跑步者当前可能正在运行：
或者它可能已经完成：
无论处于何种状态，单击 running 或 passed 图标（如果遇到问题，则单击 failed）以查看 CI 运行的当前状态。 您可以通过单击顶部的 Pipelines 菜单获得类似的视图。
您将被带到管道概览页面，您可以在其中查看 GitLab CI 运行的状态：
在 Stages 标题下，将有一个圆圈指示运行中每个阶段的状态。 如果您单击舞台，您可以看到与该舞台关联的各个作业：
单击 build 阶段中的 install_dependencies 作业。 这将带您进入工作概览页面：
现在，不再显示有关没有可用跑步者的消息，而是显示作业的输出。 在我们的例子中，这意味着您可以看到 npm 安装每个包的结果。
在右侧，您还可以看到其他一些项目。 您可以通过更改 Stage 并单击下面的运行来查看其他作业。 您还可以查看或下载运行产生的任何工件。
结论
在本指南中，我们向 GitLab 实例添加了一个演示项目，以展示 GitLab CI 的持续集成和部署功能。 我们讨论了如何在 gitlab-ci.yml 文件中定义管道来构建和测试您的应用程序，以及如何将作业分配给阶段以定义它们之间的关系。 然后，我们设置了一个 GitLab CI 运行器来为我们的项目挑选 CI 作业，并演示了如何查找有关单个 GitLab CI 运行的信息。
