.gitlab-ci.yml语法完整解析(三)
关于如何编写GitLab流水线,.gitlab-ci.yaml
文件的关键词,已经写过两期了,gitlab-ci.yaml的关键词一共有28个,分别是
分别是 script
, after_script
, allow_failure
, artifacts
, before_script
, cache
, coverage
, dependencies
, environment
, except
, extends
, image
, include
, interruptible
, only
, pages
, parallel
, release
, resource_group
, retry
, rules
, services
, stage
, tags
, timeout
, trigger
, variables
, when
第一期 .gitlab-ci.yml关键词完整解析(一) 讲了最常用的9个关键词的用法,
script
,image
,artifacts
,tags
,cache
,stage
,when
,only/except
,
第二期.gitlab-ci.yml关键词完整解析(二)讲了11个扩展性很强的关键词的用法
before_script
, after_script
, dependencies
, environment
, extends
, include
, interruptible
,parallel
, rules
,trigger
, services
这次讲一下剩余的8个关键词
allow_failure
, coverage
, pages
release
resource_group
retry
timeout
variables
allow_failure
allow_failure
是一个布尔类型, true
或false
, 默认为false
,表示当前任务是否允许失败。有这样一个应用场景,在使用eslint检查代码的时候,如果团队管理松散,可以将在eslint的任务下设置allow_failure: true
,(其实这样还不如去掉这个任务那,手动狗头) 这样即使这个任务报错了,流水线也会继续往下走。如果一个任务设置了allow_failure: true
,并且这个任务报错了,那么它将会显示黄色警告。但有种情况任务失败了也会停止的, 那就是任务设置了when: manual
,即手动操作的任务。手动启动的任务,报错了就会停止,不会继续执行后续任务,除非在rule
设置报错的处理逻辑。
coverage
coverage
是用于获取项目的代码覆盖率,这个配置项的值只能是一个正则表达式,官方有提供一些,在CICD的General pipelines里
覆盖率可以添加到项目的readme上,像这样的。
pages
pages
是一项特殊的工作,用于将静态内容上传到GitLab
,可用于为您的网站提供服务,其实就是可以托管你的网站。它具有特殊的语法,因此必须满足以下两个要求:
- 任何静态内容都必须放在
public/
目录下。 - 制品artifacts必须是目录
public/
,就是编译后的文件必须存放在public
中
下面的示例将所有文件从项目的根目录移至public/
目录。这里必须先创建一个.public
目录,防止根目录下已经存在public
了,导致循环复制。
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
only:
- master
release
release
关键词是用于创建一个release
,即创建一个发布,
创建一个发布,可以配置这些内容
tag_name
tag 名称description
描述name
名称ref
提交的hash值milestones
要关联的里程碑released_at
创建时间
ios-release:
script:
- echo 'iOS release job'
release:
tag_name: v1.0.0-ios
description: 'iOS release v1.0.0'
resource_group
有时在环境中同时运行多个作业或流水线时可能会导致在部署过程中出错。
为了避免这些错误,resource_group
可以使用该属性来确保运行程序不会同时运行某些任务。资源组的行为类似于其他编程语言中的信号灯。
当一个任务设置了resource_group
, 同一项目的不同管道之间任务的运行是互斥的。如果属于同一资源组的多个任务同时进入队列,则运行程序仅选择其中一个作业。其他作业将等到 resource_group
释放。
deploy-to-production:
script: deploy
resource_group: production
在这种情况下,两个deploy-to-production
单独流水线中的两个作业永远无法同时运行。最后的结果及时你可以确保永远不会在生产环境中发生并发部署。
您可以为每个环境定义多个资源组。例如,当部署到物理设备时,您可能有多个物理设备。可以将每个设备部署到,但是在任何给定时间每个设备只能部署一个。
resource_group
值只能包含字母,数字,-
, _
, /
, $,
{
, }
, .
,和空格。它不能以开头或结尾/。
retry
retry
可以设置一个任务的重试次数,值的类型是数字 最大是2
,如果设置2
,就表明该任务最多可以执行3次,其中包括2次重试。对于网络不稳定的部署,非常有用。
test:
script: rspec
retry: 2
timeout
timeout是用于设置一个任务的超时时间,
你也可以设置一个项目级别的超时时间。在CICD的设置中
build:
script: build.sh
timeout: 3 hours 30 minutes
test:
script: rspec
timeout: 3h 30m
variables
variables
可以让你在yaml
文件中定义变量,变量可以设置全局的,也可以是单个任务内定义。然后在script
或者执行的命中使用,定义和使用的示例,
variables:
DEPLOY_SITE: "https://example.com/"
deploy_job:
stage: deploy
script:
- deploy-script --url $DEPLOY_SITE --path "/"
deploy_review_job:
stage: deploy
variables:
REVIEW_PATH: "/review"
script:
- deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
变量名一般大写,使用时使用$
加变量名
写在最后
到这里,.gitlab-ci.yaml
的关键词解释就写完了。相信大家对GitLab
流水线的配置都有个大致的印象,剩下的就是多多地锻炼。
- 分享
- 举报
-
浏览量:14451次2020-12-02 16:57:03
-
浏览量:14026次2020-12-06 17:48:56
-
浏览量:2046次2024-01-15 16:17:45
-
浏览量:3251次2020-08-14 18:37:03
-
浏览量:3232次2020-11-28 17:56:08
-
浏览量:6130次2021-12-21 09:00:28
-
浏览量:851次2022-09-03 09:00:55
-
浏览量:1094次2023-08-11 18:18:49
-
浏览量:1621次2020-03-19 10:09:21
-
浏览量:3237次2020-10-09 10:19:29
-
浏览量:4190次2021-04-16 10:56:40
-
浏览量:3227次2022-03-12 09:00:13
-
浏览量:1464次2020-08-30 00:47:44
-
浏览量:1950次2018-11-20 22:11:24
-
浏览量:3972次2021-04-02 09:47:41
-
浏览量:1990次2019-10-15 16:27:29
-
浏览量:5949次2021-07-01 16:47:45
-
浏览量:2019次2018-04-16 11:35:00
-
浏览量:147次2023-08-23 09:02:52
-
广告/SPAM
-
恶意灌水
-
违规内容
-
文不对题
-
重复发帖
这把我C
感谢您的打赏,如若您也想被打赏,可前往 发表专栏 哦~
举报类型
- 内容涉黄/赌/毒
- 内容侵权/抄袭
- 政治相关
- 涉嫌广告
- 侮辱谩骂
- 其他
详细说明