在 GitLab 上构建 CI 流水线 | Linux 中国

导读：连续集成（CI）是指代码变更会被自动构建和测试。以下是我为自己的 C++ 项目构建 CI 流水线的过程。

本文字数：3626，阅读时长大约： 5分钟

连续集成(continuous integration)（CI）是指代码变更会被自动构建和测试。以下是我为自己的 C++ 项目构建 CI 流水线的过程。

本文介绍如何在 gitlab.com 上配置 CI 流水线。我在前面的文章中介绍了 和 linux.cn。本文将在此基础上进一步配置 CI 流水线。我会先演示如何布设和运行 CI 流水线，然后再介绍如何配置它。

CI 是指提交到代码仓库的代码变更会被自动构建和测试。在开源领域，GitLab 是一个流行的 CI 流水线平台。除了作为中心 Git 仓库外，GitLab 还提供 CI/CD 流水线、问题跟踪(issue tracking) 和 容器注册表(container registry)功能。

相关术语

在进入正题之前，我先介绍在本文和 docs.gitlab.com 中会遇到的常见术语。

◈ 持续交付(continuous delivery)（CD）：自动化供应软件，以供随时交付

◈ 持续部署(continuous deployment)（CD）：自动化软件发布

◈ 流水线(pipeline): CI/CD 的直接构件，它由阶段和作业构成

◈ 阶段(stage)：一组作业

◈ 作业(job)：某项需要执行的具体任务，比如编译、单元测试等

◈ 执行器(runner)：实际执行作业的服务

布设 CI 流水线

在下面的章节中，我将复用以前的 gitlab.com。点击 GitLab 仓库页面右上角的 复刻(Fork) 按钮复刻代码仓库。

Fork the project

设置执行器

为了让你对整个流程有所了解，我们先从在本地安装执行器讲起。

参照执行器服务 docs.gitlab.com 安装好服务，然后注册执行器。

1、选择 GitLab 项目页面左侧的 设置(Settings)，再选择 CI/CD。

Select CI/CD in Settings

2、展开 执行器(Runners) 区域，关闭 共享的执行器(Shared runners) 选项（黄框处）。特别注意令牌和 URL（绿框处），下一步会用到它们。

Configure runner

3、在终端中运行gitlab-runner register，根据提示输入以下注册信息：

◈ GitLab 实例: （如上图）

◈ 注册令牌：从执行器区域中获取 （如上图）

◈ 描述：按需自由填写

◈ 标签：可以不填

◈ 执行环境：选Shell

如果有需要，你可以在~/.gitlab-runner/config.toml中修改这些配置。

4、用命令gitlab-runner run启动执行器。你可以在 GitLab 的项目设置界面执行器区域看到执行器的状态：

Available specific runners

运行流水线

前面已经提过，流水线就是一组由执行器执行的作业。每个推送到 GitLab 的提交都会生成一个附加到该提交的流水线。如果多个提交被一起推送，那么只会为最后一个提交生成流水线。为了演示，我直接在 GitLab 在线编辑器中提交和推送修改。

打开README.md文件，添加一行数据：

Web editor

现在提交修改。

这里注意默认的行为是为提交新建一个分支，为了简便起见，我们择提交到主分支。

Commit changes

提交后一会儿后，你就应该改能看到 GitLab 执行器执行的控制台中有输出消息：

1. Checking for jobs... received job=1975932998 repo_url= runner=Z7MyQsA6

3. Job succeeded duration_s=3.866619798 job=1975932998 project=32818130 runner=Z7MyQsA6

在 GitLab 项目概览界面左侧选择 CI/CD --> 管道(Pipelines)，查看最近执行的流水线：

Pipeline overview

选中流水线可以在详情界面看到哪些作业失败了，并能查看各个作业的输出。

当遇到非零返回值是就认为作业执行失败了。在下面的例子中我通过调用exit 1强制让作业执行失败：

Job overview

CI 配置

阶段、流水线和作业的配置都在仓库根目录的 gitlab.com 文件中。我建议使用 GitLab 内置的流水线编辑器，它会自动对配置进行检查。

1. stages:

2. - build

3. - test

5. build:

6. stage: build

7. script:

8. - cmake -B build -S .

9. - cmake --build build --target Producer

10. artifacts:

11. paths:

12. - build/Producer

14. RunGTest:

15. stage: test

16. script:

17. - cmake -B build -S .

18. - cmake --build build --target GeneratorTest

19. - build/Generator/GeneratorTest

21. RunCTest:

22. stage: test

23. script:

24. - cmake -B build -S .

25. - cd build

26. - ctest --output-on-failure -j6

文件中定义了两个阶段：build和test，以及三个作业：build、RunGTest和RunCTest。其中作业build属于一个同名的阶段，另外两个作业属于阶段test。

script小节下的命令就是一般的 Shell 命令。你可以认为是将它们逐行输入到 Shell 中。

我要特别提及 产物artifact 这个特性。在示例中我定义了二进制的Producer为作业build的产物。产物会被上传到 GitLab 服务器，并且可以从服务器的这个页面上被下载：

Pipeline artifacts

默认情况下，后续阶段的作业会自动下载先前阶段作业生成的所有产物。

你可以在 docs.gitlab.com 上查看gitlab-ci.yml参考指南。

总结

上面只是一个最基本的例子，让你对持续集成的一般原则有一个了解。再演示中我禁用了共享执行器，然而这才是 GitLab 的优势所在。你可以在一个干净的容器化的环境中构架、测试和部署程序。除了使用 GitLab 提供的免费执行器，你也可以用自己的容器作为执行器。当然还有更高阶的用法：用 Kubernetes 来协调调度执行者容器，让流水线适应大规模使用的使用场景。如需进一步了解，可以查看 about.gitlab.com。

如果你使用的是 Fedora，需要注意的一点是目前 GitLab 执行者还不支持用 Podman 作为容器引擎。（LCTT 译注：Podman 是 Fedora 自带的容器引擎。）根据 议题(issue) gitlab.com，对 Podman 支持已将列上日程。（LCTT 译注：Podman 4.2 及以上版本增加了对于 GitLab 执行器的支持。）

把重复性的操作描述成作业，并将作业合并成流水线和阶段，可以让你跟踪它们的质量而不增加额外工作。。特别是在大型社区项目中，适当配置的 CI 可以告诉你提交的代码是否对项目有改善，为你接受或拒绝合并请求提供依据。

（题图：MJ/fb711c48-251a-4726-a41c-247370e5df25）

via:

作者： 选题： 译者： 校对：

本文由 原创编译， 荣誉推出

LCTT 译者 ：Xiangbin Ma

翻译： 12.0 篇

贡献： 3332 天

2014-07-01

2023-08-15

https://linux.cn/lctt/toknow-gh

欢迎遵照 CC-BY-SA 协议规定转载，

如需转载，请在文章下留言 “ 转载：公众号名称”，

我们将为您添加白名单，授权“ 转载文章时可以修改”。