介绍
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实例将受到使用我们加密的SSL的保护。 您的服务器需要具有与之关联的域名或子域才能完成此步骤。
您可以使用以下教程完成这些要求：
- 使用Ubuntu进行初始服务器安装16.04 ：创建
sudo用户并配置基本防火墙 - 如何在Ubuntu 16.04上安装和配置GitLab ：在服务器上安装GitLab
- 如何保护GitLab，让我们加密Ubuntu 16.04 ：安全的GitLab，让我们加密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并单击右上角的加号图标 ，然后选择新建项目以添加新项目：
在新项目页面上，在项目名称字段中输入项目的名称 。 GitHub上的存储库称为hello_hapi ，因此我们将使用：
接下来，点击“ 导入项目”部分下的“ 按网址Repo”按钮。 虽然有一个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配置应如下所示：
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中查看或下载，因此这对构建工件（如二进制文件）也很有用。 如果要保存舞台中生成的所有内容，请使用untracked: true替换整个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运行，以查看待处理状态下的作业。 一旦有跑步者可用，它将立即拿起等待运行。
返回到hello_hapi GitLab项目库视图中，单击分支和项目名称旁边的加号 ，然后从菜单中选择新建文件 ：
在下一页，在文件名字段中输入dummy_file ，并在主编辑窗口中输入一些文本：
完成后单击底部的提交更改 。
现在，返回到主项目页面。 一个小的暂停图标将附加到最近的提交。 如果您将鼠标悬停在图标上，它将显示“提交：待定”：
这意味着验证代码更改的测试尚未运行。
要获取更多信息，请转到页面顶部，然后单击管道 。 您将进入管道概览页面，您可以在其中看到，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-ci-multi-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赛跑者
接下来，我们需要设置一个GitLab CI转轮，以便它可以开始接受工作。
为此，我们需要一个GitLab转轮标记，以便跑步者可以使用GitLab服务器进行身份验证。 我们需要的令牌类型取决于我们如何使用这个跑步者。
如果您对跑步者有特定要求，则项目特定的赛跑者很有用。 例如，如果您的gitlab-ci.yml文件定义了需要凭据的部署任务，则可能需要特定的运行程序才能正确地向部署环境进行身份验证。 如果您的项目在CI流程中具有资源密集型步骤，这也可能是一个好主意。 项目专员不会接受其他项目的工作。
另一方面， 共享跑步者是可以被多个项目使用的通用跑步者。 赛跑者将根据计算每个项目当前正在运行的作业数量的算法从项目中获取作业。 这种跑步者更灵活。 您需要使用管理员帐户登录GitLab才能设置共享跑步者。
我们将演示如何获得以下这两个跑步者的跑步者标记。 选择最适合您的方法。
收集信息以注册项目特定的赛跑者
如果您希望赛跑者与特定项目相关联，请先浏览GitLab界面中的项目页面。
从这里，单击顶部导航栏中的设置项。 然后，单击子菜单中的CI / CD管道项目：
在该页面上，您将在左侧看到一个特定的赛跑者部分，详细介绍如何注册项目特定的赛跑者。 复制第3步中显示的注册令牌：
如果您希望禁用此项目的任何活动共享跑步者，可以单击右侧的“ 禁用共享赛跑者”按钮。 这是可选的。
准备好后，请跳过前往，了解如何使用您从本页收集的信息注册您的跑步者。
收集信息注册一个共享的赛跑者
要查找注册共享跑步者所需的信息，您需要使用管理帐户登录。
首先点击顶部导航栏中的扳手图标访问管理区域。 在“ 概述”部分中，单击“运行器”以访问共享运行程序配置页面：
复制向页面顶部显示的注册令牌：
我们将使用此令牌为项目注册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镜像（例如：ruby：2.1）
当.gitlab-ci.yml文件不包含图像规范时用于运行作业的默认图像。 最好在这里指定一般的图像，并按照我们.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 Run
返回您的网页浏览器，返回到GitLab中的项目。 根据注册赛跑者的时间长短，赛跑者可能正在运行：
或者可能已经完成：
无论状态如何，单击正在运行或传递的图标（如果遇到问题，则失败 ），以查看CI运行的当前状态。 您可以通过点击顶部的管道菜单获得类似的视图。
您将进入管道概述页面，您可以在其中看到运行GitLab CI的状态：
在阶段标题下，会有一个圆圈，表示运行中每个阶段的状态。 如果您点击舞台，您可以看到与舞台相关联的各个作业：
单击构建阶段中的install_dependencies工作。 这将带您进入作业概述页面：
现在，不显示有关没有赛跑者可用的消息，而是显示作业的输出。 在这种情况下，这意味着您可以看到npm安装每个软件包的结果。
沿着右侧，您还可以看到其他一些项目。 您可以通过更改舞台并点击下面的运行来查看其他作业。 您还可以查看或下载运行中生成的任何工件。
结论
在本指南中，我们向GitLab实例添加了一个演示项目，以展示GitLab CI的持续集成和部署功能。 我们讨论了如何在gitlab-ci.yml文件中定义一个管道来构建和测试应用程序，以及如何将作业分配到阶段来定义它们之间的关系。 然后，我们设置了一个GitLab CI运行器，为我们的项目选择CI作业，并展示了如何查找有关单个GitLab CI运行的信息。
