其他分享
首页 > 其他分享> > GitLab CI/CD关键词(七):继承 extends,自动阻断interruptible

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