GitLab CI/CD关键词(七):继承 extends,自动阻断interruptible
作者:互联网
转载自:https://cloud.tencent.com/developer/article/2003739
简介
本篇文章给大家介绍二个关键词,一个是用于优化流水线写法的关键词extends,另一个关键词 interruptible 可以将项目旧的流水线自动取消的。这两个关键词对于流水线的优化都起着很重要的作用。下面来详细看一下他们的用法。
继承 extends
extends关键词可以极大地提高流水线代码的复用率,虽然在YAML文件中,我们使用YAML锚点的功能来达到代码复用的功能,这种方式比较复杂,而且书写起来不太美观。下面是使用YAML锚点进行复用的一个例子
defaults: &defaults
adapter: postgres
host: localhost
test:
database: myapp_test
<<: *defaults
你必须要使用&,<< ,*,
三个奇怪的符号,非常怪异,不符合书写习惯。
下面看一下使用extends的用法。
首先 extends是一个作业关键词,这也意味着你只能在作业上使用它,另外一个就是extends的值可以是一个或多个作业名称,而这些作业的内容将会被合并到当前的作业中 下面看一个具体的例子
.Irelia:
stage: test
only:
- master
test_job:
extends: .Irelia
script: echo 'Ionia shall not fall'
上面的例子定义了一个作业模板.Irelia,或者叫做一个已经注释的作业,它的作业名以.开头,并不会真正运行。在test_job中,我们使用extends继承了它,那么.Irelia作业的内容将与test_job合并。如果有重名的key,则以test_job为主。只合并key,不会合并key对应的值。
合并后 test_job的内容就变成了
test_job:
stage: test
script: echo 'Ionia shall not fall'
only:
- master
除此之外你还要看配置多个作业模板如 以下
test_job:
extends: [.Irelia, .Ashe, .Yi]
script: echo 'Ionia shall not fall'
除了继承当前yaml的模板作业,你也可以继承使用include 引入的模板作业。 如下:
included.yml
.template:
script:
- echo Hello!
.gitlab-ci.yml
include: included.yml
useTemplate:
image: alpine
extends: .template
下面有一个更为复杂的例子,大家可以学习一下。
原始代码
.only-important:
variables:
URL: "http://my-url.internal"
IMPORTANT_VAR: "the details"
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $CI_COMMIT_BRANCH == "stable"
tags:
- production
script:
- echo "Hello world!"
.in-docker:
variables:
URL: "http://docker-url.internal"
tags:
- docker
image: alpine
rspec:
variables:
GITLAB: "is-awesome"
extends:
- .only-important
- .in-docker
script:
- rake rspec
真正执行的代码
rspec:
variables:
URL: "http://docker-url.internal"
IMPORTANT_VAR: "the details"
GITLAB: "is-awesome"
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $CI_COMMIT_BRANCH == "stable"
tags:
- docker
image: alpine
script:
- rake rspec
自动阻断 interruptible
在运行流水线时,有时会遇到这样一种情况,在修改bug或处理紧急事项时,会频繁地发到研发环境或测试环境进行验证。在这种情况下,会有这样一种情况,在短时间内,在同一分支,提交多次代码,触发多条流水线,流水线将并行运行。这种情况可能会造成系统超载,而且部署的结果有时是无法保证的,因为在并发运行环境下,受各种因素的影响,“旧代码的流水线”会比“新代码的流水线”部署更晚。
为了解决这一问题,GitLab CI/CD提供了一种功能,就是当一个分支的流水线多次被触发时,可以设置自动取消旧的流水线。这里用到的就是关键词interruptible。
关键词interruptible的值只能是true或false,默认为false,意味着默认:当有新的流水线被触发时,旧的流水线是不会自动取消旧的。
注意这里有一个细节,就是如果你在A分支提交代码,触发了流水线PA,然后再通过Web页面手动触发流水线,这种情况不会取消正在运行的PA流水线。(亲测,版本V14.0)
此外还有重要的一点是,关键词interruptible必须搭配 CI/CD的配置项一起使用才有效。必须勾选以下配置,否则不会自动取消同分支旧流水线。
还有一点需要注意,当流水线运行过了interruptible:false的作业后,该流水线就不会被自动取消了。
看一下这个例子
stages:
- stage1
- stage2
- stage3
step-1:
stage: stage1
script:
- echo "Can be canceled."
interruptible: true
step-2:
stage: stage2
script:
- echo "Can not be canceled."
step-3:
stage: stage3
script:
- echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
interruptible: true
当流水线运行到了step-2时,该流水线不会被取消,运行到step-3时也不会被取消。
如果你要想让流水线不管在哪个作业下都可以取消运行,可以在default关键词下设置interruptible:true。在部署作业上慎用。
标签:CI,script,GitLab,作业,CD,interruptible,extends,test,流水线 来源: https://www.cnblogs.com/sanduzxcvbnm/p/16377500.html