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