| 编辑推荐: |
本文来自腾讯云，文章介绍了如何设置GitLab
CI以监视存储库的更改并运行自动化测试以验证新代码等相关知识。 |
|
介绍
GitLab Community Edition是一个自托管的Git存储库提供程序，具有帮助项目管理和软件开发的附加功能。GitLab提供的最有价值的功能之一是内置的持续集成和交付工具GitLab
CI。
在本教程中，我们将演示如何设置GitLab CI以监视存储库的更改并运行自动化测试以验证新代码。我们将从运行的GitLab安装开始，我们将为基本的Node.js应用程序复制示例存储库。在配置我们的CI过程之后，当新的提交被推送到存储库时，GitLab将使用CI
runner来针对隔离的Docker容器中的代码执行测试套件。
准备
在开始之前，您需要设置一个初始环境。我们需要一个安全的GitLab服务器，用于存储我们的代码并管理我们的CI/CD流程。此外，我们需要一个地方来运行自动化测试。这个地方可以是GitLab所在的服务器，也可以是单独的主机，详情请看下面的教程。
使用SSL保护的GitLab服务器
要存储源代码并配置我们的CI/CD任务，我们需要在Ubuntu 16.04服务器上安装GitLab实例。GitLab目前推荐一款至少具有2个CPU内核和4GB内存的服务器。可以直接使用腾讯云服务器作为GitLab服务器，如果你有域名，保护你网站的最简单方法是使用腾讯云SSL证书服务，它提供免费的可信证书。
我们将演示如何在项目之间共享CI/CD运行程序（运行自动化测试的组件）以及如何将它们锁定到单个项目。如果您希望在项目之间共享CI
runners ，我们强烈建议您限制或禁用公共注册。
一个或多个服务器用作GitLab CI Runners
GitLab CI Runners是检查代码并运行自动化测试以验证新更改的服务器。为了隔离测试环境，我们将在Docker容器中运行所有自动化测试。为此，我们需要在将运行测试的服务器或服务器上安装Docker。
从GitHub复制示例存储库
首先，我们将在GitLab中创建一个包含示例Node.js应用程序的新项目。我们将直接从GitHub导入原始存储库，这样我们就不必手动上传它。
登录GitLab并单击右上角的加号图标，然后选择新建项目以添加新项目：
在新项目页面上，单击“ 导入项目”选项卡：
接下来，单击Repo by URL按钮。虽然有一个GitHub导入选项，但它需要一个Personal访问令牌，用于导入存储库和其他信息。我们只对代码和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：
接下来，我们明确定义将运行的不同持续集成阶段：
您在此处选择的名称是任意的，但顺序决定了后续步骤的执行顺序。Stages是可以应用于单个作业的标签。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/ |
任务名称可以自定义，通常，npm install可以与下一个测试阶段结合使用，但为了更好地演示阶段之间的交互，我们正在提取此步骤以在其自己的阶段中运行。
我们将该阶段明确标记为使用stage指令的“build”。接下来，我们指定使用script指令运行的实际命令。您可以通过在script部分中添加其他行来包含多个命令。
artifacts子部分用于指定要在阶段之间保存和传递的文件或目录路径。由于npm
install命令会为项目安装依赖项，因此下一步将需要访问下载的文件。声明node_modules路径可确保下一个阶段可以访问文件。这些也可以在测试后在GitLab
UI中查看或下载，因此这对于二进制文件等构建工件也很有用。如果要保存现阶段中生成的所有内容，请将整个paths部分替换为untracked:true。
最后，第二个名为test_with_lab的任务声明了实际运行测试套件的命令：
test_with_lab:
stage: test
script: npm test |
script: npm test
我们把它放在test阶段。由于这是后期阶段，因此它可以访问build阶段生成的工件，这是我们案例中的项目依赖关系。这里，script部分演示了当只有一个项目时可以使用的单行YAML语法。我们可以在之前的作业中使用相同的语法，因为只指定了一个命令。
现在您已经了解.gitlab-ci.yml文件如何定义CI/CD任务，我们可以定义一个或多个能够执行测试计划的运行程序。
触发持续集成运行
由于我们的存储库包含一个.gitlab-ci.yml文件，因此任何新的提交都将触发新的CI运行。如果没有可用的runner，则CI运行将设置为“pending”。在我们定义运行器之前，让我们触发CI运行以查看任务在待处理状态下的状态。一旦runner可用，它将立即开始运行。
回到hello_hapiGitLab项目存储库视图，单击分支和项目名称旁边的加号，然后从菜单中选择New
file：
在接下来的页面中，在文件名称字段输入dummy_file并在主编辑窗口中输入一些文字：
完成后，单击底部的提交更改。
现在，返回主项目页面。最近的提交将附加一个小的暂停图标。如果将鼠标悬停在图标上，则会显示“Commit:pending”：
这意味着验证代码更改的测试尚未运行。
要获取更多信息，请转到页面顶部，然后单击“Piplines”。您将进入pipeline概述页面，您可以在其中看到CI运行被标记为待处理并标记为“stuck”：
注意：右侧是CI Lint工具的按钮。您可以在此处检查您编写的任何gitlab-ci.yml文件的语法。
从这里，您可以单击pending状态以获取有关运行的更多详细信息。此视图显示我们运行的不同阶段，以及与每个阶段关联的各个任务：
最后，单击install_dependencies任务。这将为您提供有关延迟运行的具体细节：
此处，该消息表明由于缺少runner而导致作业停滞。这是预料之中的，因为我们还没有配置任何。一旦runner可用，可以使用相同的界面查看输出。这也是您可以下载构建期间生成的工件的位置。
现在我们知道待处理的任务是什么样的，我们可以为我们的项目分配一个CI运行器来获取待处理的任务。
安装GitLab CI Runner服务
我们现在准备建立一个GitLab CI runner。为此，我们需要在系统上安装GitLab
CI runner包并启动GitLab runner服务。该服务可以为不同的项目运行多个运行程序实例。
安装GitLab CI runner服务的过程类似于用于安装GitLab本身的过程。我们将下载一个脚本，将GitLab存储库添加到apt源列表中。运行脚本后，我们将下载runner包。然后我们可以将其配置为服务我们的GitLab实例。
首先将最新版本的GitLab CI runner存储库配置脚本下载到/tmp目录
| $ 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
runner包。完成后，您可以使用apt-get命令继续安装：
| $ sudo apt-get
install gitlab-runner |
这将在系统上安装GitLab CI runner包并启动GitLab
runner服务。
设置GitLab Runner
接下来，我们需要设置一个GitLab CI runner，以便它可以开始接受任务。
为此，我们需要一个GitLab runner令牌，以便运行器可以使用GitLab服务器进行身份验证。我们需要的令牌类型取决于我们如何使用此runner。
如果您对于runner有具体要求，具体项目runner将会非常有用。例如，如果您的gitlab-ci.yml文件定义了需要凭据的部署任务，则可能需要特定的运行程序在部署环境中正确进行身份验证。特定于项目的runner不接受来自其他项目的任务。
另一方面，共享runner是可以由多个项目使用的通用runner。Runner将根据一种算法从项目中获取任务，该算法考虑了每个项目当前正在运行的任务数量。这种类型的runner更灵活。您需要使用管理员帐户登录GitLab以设置共享runner。
我们将演示如何获得以下两种runner类型的runner令牌。选择最适合您的方法。
收集信息以注册特定项目的runner
如果您希望将runner绑定到特定项目，请首先导航到GitLab界面中的项目页面。
在此处，单击左侧菜单中的“设置”项。然后，单击子菜单中的CI / CD项：
在此页面上，您将看到“ runner设置”部分。单击“展开”按钮以查看更多详细信息。在详细视图中，左侧将说明如何注册项目特定的runner。复制说明的第4步中显示的注册令牌：
如果要为此项目禁用任何活动的共享运行程序，可以通过单击右侧的“禁用共享运行程序”按钮来执行此操作。这是可选的。
准备就绪后，请跳过前面的内容，了解如何使用您从此页面收集的信息注册runner。
收集信息以注册共享runner
要查找注册共享运行程序所需的信息，您需要使用管理帐户登录。
首先，单击顶部导航栏中的扳手图标以访问管理区域。在左侧菜单的“概述”部分中，单击“Runner”以访问共享运行器配置页面：
将显示的注册令牌复制到页面顶部：
我们将使用此令牌为项目注册GitLab CI runner。
使用GitLab服务器注册GitLab CI Runner
现在您有了令牌，请返回安装了GitLab CI runner服务的服务器。
要注册新的runner，请输入以下命令：
| $ sudo gitlab-runner
register |
您将被问到一系列问题来配置runner：
Please enter the gitlab-ci coordinator
URL (e.g. https://gitlab.com/)
输入您的GitLab服务器的域名，https://用于指定SSL。您可以选择附加/ci到域的末尾，但最新版本会自动重定向。
Please enter the gitlab-ci token for
this runner
您在上一部分中复制的令牌。
Please enter the gitlab-ci description
for this runner
这个特定runner的名字。这将显示在命令行和GitLab界面中的runner服务的runner列表中。
Please enter the gitlab-ci tags for
this runner （逗号分隔）
这些是您可以分配给runner的标签。GitLab作业可以表达这些标记的要求，以确保它们在具有正确依赖关系的主机上运行。在这种情况下，您可以将此处留空。
Whether to lock Runner to current
project true/false
将runner分配给特定项目。它不能被其他项目使用。在这里选择“false”。
Please enter the executor
runner用来完成任务的方法。在这里选择“docker”。
Please enter the default Docker image
(e.g. ruby:2.1)
当.gitlab-ci.yml文件不包含镜像特性时，该默认镜像将用于运行任务。最好在此处指定一般镜像，并像我们一样在.gitlab-ci.yml文件中定义更具体的镜像。
我们将在这里输入“alpine：latest”作为一个小的，安全的默认值。
在回答提示后，将创建一个能够运行项目的CI/CD任务的新runner。
您可以通过输入以下内容来查看GitLab CI转轮服务当前具有的runner：
| $ sudo gitlab-runner
list |
Listing configured
runners ConfigFile=/etc/gitlab-runner/config.toml
example-runner Executor=docker Token=e746250e282d197baa83c67eda2c0b
URL=https://example.com |
现在我们有一个runner，我们可以回到GitLab的项目。
在GitLab中查看CI/CD运行
返回Web浏览器，返回GitLab中的项目。根据注册runner的时间长短，runner可能正在运行：
或者它可能已经完成：
无论状态如何，单击正在运行或已通过的图标（如果遇到问题，则会失败）以查看CI运行的当前状态。单击顶部“Pipeline”菜单可以获得类似的视图。
您将进入pipeline概述页面，您可以在其中查看GitLab CI运行的状态：
在Stages标题下，将有一个圆圈表示运行中每个阶段的状态。如果单击stage，则可以看到与stage关联的各个任务：
单击构建阶段中的install_dependencies任务。这将带您进入任务概述页面：
现在，不显示关于没有可用的runner的消息，而是显示任务的输出。在我们的例子中，这意味着您可以看到npm安装每个包的结果。
在右侧，您还可以看到其他一些项目。您可以通过更改阶段并单击下面的运行来查看其他任务。您还可以查看或下载运行生成的任何工件。
结论
在本教程中，我们向GitLab实例添加了一个演示项目，以展示GitLab
CI的持续集成和部署功能。我们讨论了如何在gitlab-ci.yml文件中定义pipeline以构建和测试应用程序，以及如何将作业分配给stage以定义彼此之间的关系。然后，我们设置了一个GitLab
CI runner来为我们的项目选择CI任务，并演示了如何查找有关各个GitLab CI运行的信息。
|
