mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
Merge pull request #29945 from wxy/20220131-How-to-set-up-a-CI-pipeline-on-GitLab
RP:published/20220131 How to set up a CI pipeline on GitLab.md
This commit is contained in:
commit
dac763865c
@ -3,18 +3,20 @@
|
||||
[#]: author: "Stephan Avenwedde https://opensource.com/users/hansic99"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "toknow-gh"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-16105-1.html"
|
||||
|
||||
在 GitLab 上构建 CI 流水线
|
||||
======
|
||||
<ruby>连续集成<rt>continuous integration</rt></ruby>(CI)是指代码变更会被自动构建和测试。以下是我为自己的 C++ 项目构建 CI 流水线的过程。
|
||||
![Plumbing tubes in many directions][1]
|
||||
|
||||
> <ruby>连续集成<rt>continuous integration</rt></ruby>(CI)是指代码变更会被自动构建和测试。以下是我为自己的 C++ 项目构建 CI 流水线的过程。
|
||||
|
||||
![][0]
|
||||
|
||||
本文介绍如何在 [GitLab][2] 上配置 CI 流水线。我在前面的文章中介绍了 [基于 CMake 和 VSCodium 的构建系统][3] 和 [基于 GoogleTest 和 CTest 的单元测试][4]。本文将在此基础上进一步配置 CI 流水线。我会先演示如何布设和运行 CI 流水线,然后再介绍如何配置它。
|
||||
|
||||
CI 是指提交到代码仓库的代码变更会被自动构建和测试。在开源领域,GitLab 是一个流行的 CI 流水线平台。除了作为中心 Git 仓库外,GitLab 还提供 CI/CD 流水线、<ruby>问题跟踪<rt>issue tracking</rt></ruby>和<ruby>容器注册表<rt>container registry</rt></ruby>功能。
|
||||
CI 是指提交到代码仓库的代码变更会被自动构建和测试。在开源领域,GitLab 是一个流行的 CI 流水线平台。除了作为中心 Git 仓库外,GitLab 还提供 CI/CD 流水线、<ruby>问题跟踪<rt>issue tracking</rt></ruby> 和 <ruby>容器注册表<rt>container registry</rt></ruby>功能。
|
||||
|
||||
### 相关术语
|
||||
|
||||
@ -29,47 +31,38 @@ CI 是指提交到代码仓库的代码变更会被自动构建和测试。在
|
||||
|
||||
### 布设 CI 流水线
|
||||
|
||||
在下面的章节中,我将复用以前的 [示例工程][6]。点击 GitLab 仓库页面右上角的 **Fork** 按钮<ruby>复刻<rt>fork</rt></ruby> 代码仓库。
|
||||
在下面的章节中,我将复用以前的 [示例工程][6]。点击 GitLab 仓库页面右上角的 <ruby>复刻<rt>Fork</rt></ruby> 按钮复刻代码仓库。
|
||||
|
||||
![Fork the project][7]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
#### Set up a runner
|
||||
#### 设置执行器
|
||||
|
||||
为了让你对整个流程有所了解,我们先从在本地安装执行器讲起。
|
||||
|
||||
参照执行器服务 [安装指南][8] 安装好服务,然后注册执行器。
|
||||
|
||||
1\. 选择 GitLab 项目页面左侧的 **Settings**,再选择 **CI/CD**。
|
||||
1、选择 GitLab 项目页面左侧的 <ruby>设置<rt>Settings</rt></ruby>,再选择 **CI/CD**。
|
||||
|
||||
![Select CI/CD in Settings][9]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
2\. 展开 **Runners** 小节,关闭 **Shared runners** 选项(黄框处)。特别注意令牌和 URL(绿框处),下一步会用到它们。
|
||||
2、展开 <ruby>执行器<rt>Runners</rt></ruby> 区域,关闭 <ruby>共享的执行器<rt>Shared runners</rt></ruby> 选项(黄框处)。特别注意令牌和 URL(绿框处),下一步会用到它们。
|
||||
|
||||
![Configure runner][10]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
3\. 在终端中运行 `gitlab-runner register`,根据提示输入以下注册信息:
|
||||
3、在终端中运行 `gitlab-runner register`,根据提示输入以下注册信息:
|
||||
|
||||
* GitLab 实例: <https://gitlab.com/> (如上图)
|
||||
* 注册令牌:从 **Runners** 小节中获取 (如上图)
|
||||
* 注册令牌:从执行器区域中获取 (如上图)
|
||||
* 描述:按需自由填写
|
||||
* 标签:可以不填
|
||||
* 执行环境:选 **Shell**
|
||||
|
||||
|
||||
如果有需要,你可以在 `~/.gitlab-runner/config.toml` 中修改这些配置。
|
||||
|
||||
4\. 用命令 `gitlab-runner run` 启动执行器。你可以在 GitLab 的项目设置界面 **Runners** 小节看到执行器的状态:
|
||||
4、用命令 `gitlab-runner run` 启动执行器。你可以在 GitLab 的项目设置界面执行器区域看到执行器的状态:
|
||||
|
||||
![Available specific runners][11]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
### 运行流水线
|
||||
|
||||
前面已经提过,流水线就是一组由执行器执行的作业。每个推送到 GitLab 的提交都会生成一个附加到该提交的流水线。如果多个提交被一起推送,那么只会为最后一个提交生成流水线。为了演示,我直接在 GitLab 在线编辑器中提交和推送修改。
|
||||
@ -78,103 +71,85 @@ Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
![Web editor][12]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
现在提交修改。
|
||||
|
||||
这里注意默认的行为是为提交新建一个分支,为了简便起见,我们择提交到主分支。
|
||||
|
||||
![Commit changes][13]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
提交后一会儿后,你就应该改能看到 GitLab 执行器执行的控制台中有输出消息:
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
Checking for jobs... received job=1975932998 repo_url=<https://gitlab.com/hANSIc99/cpp\_testing\_sample.git> runner=Z7MyQsA6
|
||||
|
||||
Job succeeded duration_s=3.866619798 job=1975932998 project=32818130 runner=Z7MyQsA6
|
||||
|
||||
```
|
||||
|
||||
在 GitLab 项目概览界面左侧选择 **CI/CD** --> **Pipelines**,查看最近执行的流水线:
|
||||
在 GitLab 项目概览界面左侧选择 CI/CD --> <ruby>管道<rt>Pipelines</rt></ruby>,查看最近执行的流水线:
|
||||
|
||||
![Pipeline overview][14]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
选中流水线可以在详情界面看到哪些作业失败了,并能查看各个作业的输出。
|
||||
|
||||
当遇到非零返回值是就认为作业执行失败了。在下面的例子中我通过调用 `exit 1` 强制让作业执行失败:
|
||||
|
||||
|
||||
![Job overview][15]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
### CI 配置
|
||||
|
||||
阶段、流水线和作业的配置都在仓库根目录的 [.gitlab-ci.yml][16] 文件中。我建议使用 GitLab 内置的流水线编辑器,它会自动对配置进行检查。
|
||||
|
||||
```
|
||||
|
||||
|
||||
stages:
|
||||
\- build
|
||||
\- test
|
||||
- build
|
||||
- test
|
||||
|
||||
build:
|
||||
stage: build
|
||||
script:
|
||||
- cmake -B build -S .
|
||||
- cmake --build build --target Producer
|
||||
artifacts:
|
||||
paths:
|
||||
- build/Producer
|
||||
stage: build
|
||||
script:
|
||||
- cmake -B build -S .
|
||||
- cmake --build build --target Producer
|
||||
artifacts:
|
||||
paths:
|
||||
- build/Producer
|
||||
|
||||
RunGTest:
|
||||
stage: test
|
||||
script:
|
||||
- cmake -B build -S .
|
||||
- cmake --build build --target GeneratorTest
|
||||
- build/Generator/GeneratorTest
|
||||
stage: test
|
||||
script:
|
||||
- cmake -B build -S .
|
||||
- cmake --build build --target GeneratorTest
|
||||
- build/Generator/GeneratorTest
|
||||
|
||||
RunCTest:
|
||||
stage: test
|
||||
script:
|
||||
- cmake -B build -S .
|
||||
- cd build
|
||||
- ctest --output-on-failure -j6
|
||||
|
||||
stage: test
|
||||
script:
|
||||
- cmake -B build -S .
|
||||
- cd build
|
||||
- ctest --output-on-failure -j6
|
||||
```
|
||||
|
||||
文件中定义了两个阶段:**build** 和 **test**,以及三个作业: **build**、 **RunGTest** 和 **RunCTest**。其中作业 **build** 属于一个同名的阶段,另外两个作业属于阶段 **test** 。
|
||||
文件中定义了两个阶段:`build` 和 `test`,以及三个作业:`build`、`RunGTest` 和 `RunCTest`。其中作业 `build` 属于一个同名的阶段,另外两个作业属于阶段 `test`。
|
||||
|
||||
**script** 小节下的命令就是一般的 shell 命令。你可以认为是将它们逐行输入到 shell 中。
|
||||
`script` 小节下的命令就是一般的 Shell 命令。你可以认为是将它们逐行输入到 Shell 中。
|
||||
|
||||
我要特别提及<ruby>产物</rt>artifact</rt></ruby> 这个特性。在示例中我定义了二进制的 _Producer_ 为作业 **build** 的产物。产物会被上传到 GitLab 服务器,并且可以从服务器的这个页面上被下载:
|
||||
我要特别提及 <ruby>产物</rt>artifact</rt></ruby> 这个特性。在示例中我定义了二进制的 `Producer` 为作业 `build` 的产物。产物会被上传到 GitLab 服务器,并且可以从服务器的这个页面上被下载:
|
||||
|
||||
![Pipeline artifacts][17]
|
||||
|
||||
Stephan Avenwedde (CC BY-SA 4.0)
|
||||
|
||||
默认情况下,后续阶段的作业会自动下载先前阶段作业生成的所有产物。
|
||||
|
||||
你可以在 [docs.gitlab.com][18] 上查看 `gitlab-ci.yml` 参考指南。
|
||||
|
||||
### 总结
|
||||
|
||||
上面只是一个最基本的例子,让你对持续集成的一般原则有一个了解。再演示中我禁用了共享执行器,然而这才是
|
||||
GitLab 的优势所在。你可以在一个干净的容器化的环境中构架、测试和部署程序。【除了使用 GitLab 提供的免费执行器,你也可以用自己的容器作为执行器。】当然还有更高阶的【用法】:用 Kubernetes 来协调调度执行者容器,让流水线适应大规模使用的使用场景。如需进一步了解,可以查看 [about.gitlab.com][19]。
|
||||
上面只是一个最基本的例子,让你对持续集成的一般原则有一个了解。再演示中我禁用了共享执行器,然而这才是 GitLab 的优势所在。你可以在一个干净的容器化的环境中构架、测试和部署程序。除了使用 GitLab 提供的免费执行器,你也可以用自己的容器作为执行器。当然还有更高阶的用法:用 Kubernetes 来协调调度执行者容器,让流水线适应大规模使用的使用场景。如需进一步了解,可以查看 [about.gitlab.com][19]。
|
||||
|
||||
如果你使用的是 Fedora,需要注意的一点是目前 GitLab 执行者还不支持用 Podman 作为容器引擎。(LCTT 译注:Podman 是 Fedora 自带的容器引擎。)根据<ruby>议题<rt>issue</rt></ruby> [#27119][20],对 Podman 支持已将列上日程。(LCTT 译注:Podman 4.2 及以上版本增加了对于 GitLab 执行器的支持。)
|
||||
如果你使用的是 Fedora,需要注意的一点是目前 GitLab 执行者还不支持用 Podman 作为容器引擎。(LCTT 译注:Podman 是 Fedora 自带的容器引擎。)根据 <ruby>议题<rt>issue</rt></ruby> [#27119][20],对 Podman 支持已将列上日程。(LCTT 译注:Podman 4.2 及以上版本增加了对于 GitLab 执行器的支持。)
|
||||
|
||||
把重复性的操作描述成作业,并将作业合并成流水线和阶段,可以让你跟踪它们的质量而不增加额外工作。。特别是在大型社区项目中,适当配置的 CI 可以告诉你提交的代码是否对项目有改善,为你接受或拒绝合并请求提供依据。
|
||||
|
||||
*(题图:MJ/fb711c48-251a-4726-a41c-247370e5df25)*
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/2/setup-ci-pipeline-gitlab
|
||||
@ -182,7 +157,7 @@ via: https://opensource.com/article/22/2/setup-ci-pipeline-gitlab
|
||||
作者:[Stephan Avenwedde][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[toknow-gh](https://github.com/toknow-gh)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
校对:[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -190,8 +165,8 @@ via: https://opensource.com/article/22/2/setup-ci-pipeline-gitlab
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/plumbing_pipes_tutorial_how_behind_scenes.png?itok=F2Z8OJV1 (Plumbing tubes in many directions)
|
||||
[2]: https://gitlab.com/
|
||||
[3]: https://opensource.com/article/22/1/devops-cmake
|
||||
[4]: https://opensource.com/article/22/1/unit-testing-googletest-ctest
|
||||
[3]: https://linux.cn/article-14249-1.html
|
||||
[4]: https://linux.cn/article-16055-1.html
|
||||
[5]: https://docs.gitlab.com/
|
||||
[6]: https://gitlab.com/hANSIc99/cpp_testing_sample
|
||||
[7]: https://opensource.com/sites/default/files/cpp_ci_cd_gitlab_fork.png (Fork the project)
|
||||
@ -208,3 +183,4 @@ via: https://opensource.com/article/22/2/setup-ci-pipeline-gitlab
|
||||
[18]: https://docs.gitlab.com/ee/ci/yaml/
|
||||
[19]: https://about.gitlab.com/solutions/kubernetes/
|
||||
[20]: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119
|
||||
[0]: https://img.linux.net.cn/data/attachment/album/202308/18/094419rahz9i5pk3n9fkkf.jpg
|
Loading…
Reference in New Issue
Block a user