gitlab服务CI/CD配置

news/2024/5/2 16:57:03/文章来源:https://blog.csdn.net/xhtchina/article/details/127009187

使用Gitlab作为工作仓库进行代码发布及版本控制，Gitlab内置了CI/CD的工具，这些工具可以用于代码提交的同时完成镜像构建、自动化测试、自动化部署等连续的工作：

CI: Continuous Integration（持续集成）
CD: Continuous Delivery（连续交付）
CD: Continuous Deployment（持续部署）
这里暂时只讨论CI持续集成部分的工作，我们常用CI来做一些自动化工作，这种自动化工作会运行在一台集中的机器上，比如程序镜像的打包，单元测试，部署等，它可以节省项目开发迭代过程中维护正确的代码所耗费的时间。

例比如CI中自动测试，在多人协同开发的过程中，可能会有频繁的不同分支的代码推送更新，使用CI管道，可在代码发布的同时触发CI中定义的单元测试操作，以便于在开发早期发现错误，从而确保所有新代码的提交都不影响项目功能。

依赖服务：

gitlab

https://www.zongscan.com/demo333/95354.html

gitlab-runner

https://www.zongscan.com/demo333/95355.html

后面有时间我也会把我自己的beego项目迁移进docker swarm集群里面来，整成自动化持续集成部署方式。

1. Gitlab-CI/CD工作流

参考下图先了解CI/CD的具体工作流和概念，黄色部分为主要涉及的概念，将在后文重点说明：

你当前的代码库托管在Gitlab上，且已经为代码仓库配置了gitlab-runner服务, 它是用来实际执行CI任务的服务器；
提交代码，且根目录中包含一个名为.gitlab-ci.yml文件，该文件是用来指定构建、测试和部署流程、以及CI触发条件的脚本，其概念类似于docker-compose.yml文件；
Gitlab检测到.gitlab-ci.yml文件，若当前提交符合文件中指定的触发条件，则会使用配置的gitlab-runner服务运行该脚本进行测试等工作；
若.gitlab-ci.yml中定义的某个自动化脚本运行失败，将判定为此次CI不通过，则需要提交者修复问题代码后重复提交，直至自动化CI通过。
没有问题的提交才能被项目负责人merge到主分支，进行后续的部署工作（此文暂不涉及CD自动化部署）

2. 配置文件介绍

.gitlab-ci.yml文件主要的作用是用来指定构建、测试和部署流程、以及CI触发条件的脚本

在文件中的定义要运行的脚本，要包含的其他配置文件和模板，依赖项和缓存，要按顺序运行的命令和要并行运行的命令，将应用程序部署到的位置。

无论您是想自动运行脚本还是手动触发其中的任何一个。

脚本被分组到作业中，作业作为更大管道的一部分运行。

您可以将多个独立作业分组到按定义顺序运行的阶段。

CI/CD 配置至少需要一项未隐藏的作业。

您应该按照适合您的应用程序并符合您希望执行的测试的顺序组织您的工作。

为了可视化该过程，假设您添加到作业的脚本与您在计算机上运行的 CLI 命令相同。

当您将 .gitlab-ci.yml 文件添加到存储库时，

GitLab 会检测到它，并且名为 GitLab Runner 的应用程序会运行作业中定义的脚本。

3. 参数列表

值	是否必须	描述
script	必须	定义由Runner执行的shell脚本或命令
extends	非必须	定义此作业将继承的配置条目
image	非必须	需要使用的docker镜像，请查阅该文档
services	非必须	定义所需的docker服务，请查阅该文档
stage	非必须	定义一个工作场景阶段，默认是test
type	非必须	stage的别名,不赞成使用
variables	非必须	在job级别上定义的变量
only	非必须	定义job所引用的git分支
except	非必须	定义job所不适用的git分支
tags	非必须	定义job所适用的runner，tags为runner标签
allow_failure	非必须	when 用于实现在发生故障或发生故障时运行的作业。 when 可以设置为以下值之一： on_success-仅当先前阶段中的所有作业都成功（或因为已标记，被视为成功allow_failure）时才执行作业。这是默认值。 on_failure -仅在前一阶段中的至少一项作业失败时才执行作业。 always -执行作业，而不管先前阶段的作业状态如何。 manual-手动执行作业（在GitLab 8.10中已添加）. delayed-一定时间后执行作业（在GitLab 11.14中已添加）。
when	非必须	定义了job什么时候执行，可以是on_success、on_failure、always和manual
dependencies	非必须	定义了该job依赖哪一个job，如果设置该项，可以通过artifacts设置
artifacts	非必须	工件，在依赖项之间传递的东西，类似cache，但原理与cache不同
cache	非必须	定义需要被缓存的文件、文件夹列表
before_script	非必须	覆盖在作业之前执行的脚本或命令
after_script	非必须	覆盖在作业之后执行的脚本或命令
environment	非必须	定义让job完成部署的环境名称
coverage	非必须	定义job设置代码覆盖率
stages	非必须	定义pipeline的全部阶段（stage），阶段内所有任务并行执行，全部执行成功开始下一阶段任务，任何阶段内任意job执行失败都会导致pipeline失败，所有stage，job执行成功后pipeline会显示pass。如果未定义stages，则默认有build、test、deploy三个阶段，如果未定义stage，则默认test阶段
rules	非必须	用于评估和确定作业的选定属性，以及是否创建该作业。不能与only/except 一起使用
include	非必须	允许此作业包括外部YAML文件。也可用：include:local，include:file，include:template，和include:remote。
interruptible	非必须	定义在通过新的运行使其冗余时是否可以取消作业。
resource_group	非必须	限制作业并发。
timeout	非必须	定义自定义作业级别的超时，该超时优先于项目范围的设置。

4. 编写说明

.gitlab-ci.yml文件中指定了CI的触发条件、工作内容、工作流程，编写和理解此文件是CI实战中最重要的一步，该文件指定的任务内容总体构成了1个pipeline、1个pipeline包含不同的stage执行阶段、每个stage包含不同的具体job脚本任务。

4.1. 配置文件说明

4.2. Pipeline说明

一个.gitlab-ci.yml文件触发后会形成一个pipeline任务流由gitlab-runner来运行处理，pipeline中stage、job概念如下，需要按照项目实际情况定义不同stage和job，自己绘制了一个流程示意图帮助理解:

5. 示例

stages:- build- test
build-code-job:stage: buildscript:- echo "Check the ruby version, then build some Ruby project files:"- ruby -v- rake
test-code-job1:stage: testscript:- echo "If the files are built successfully, test some files with one command:"- rake test1
test-code-job2:stage: testscript:- echo "If the files are built successfully, test other files with a different command:"- rake test2