使用Gitlab Template加强GitLab CICD的扩展性和兼容性

前期导读:git

Include指令

Func: 用于引入.yml.yaml结尾的YAML文件,其余类型的文件不能引入。咱们能够利用include.gitlab-ci.yml文件的结构更清晰,同时也能够把一些须要集中管理维护的job写在一个YAML文件中,放在一个公共仓库,让其余项目的CI来引入该文件。web

举个例子,假如每一个团队都须要执行一个report的job,用于报告版本发布的相关信息,那么咱们能够把这个job写在report.yml文件,放在一个公共的仓库,而后每一个团队的.gitlab-ci.yml文件引入report.yml。假如之后须要在report中添加一些须要上报的内容,只须要修改公共项目的report.yml便可。固然,因为report.yml会被多个项目引用,因此必须通用且拥有较好的扩展性与兼容性,若是改一点东西都须要每一个团队去配合你改,那就比较糟糕了。微信

include注意要点假设模板文件 example.yml 内容以下:dom

variables:
  POSTGRES_USER: user
  POSTGRES_PASSWORD: testing_password
  POSTGRES_DB: $CI_ENVIRONMENT_SLUG

production:
  stage: production
  script:
    - install_dependencies
    - deploy
  environment:
    name: production
    url: https://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
  only:
    - master

.gitlab-ci.yml 内容以下:编辑器

include: 'example.yml'

image: alpine:latest

variables:
  POSTGRES_USER: root
  POSTGRES_PASSWORD: secure_password

stages:
  - build
  - test
  - production

production:
  environment:
    url: https://domain.com
  • include的文件和 .gitlab-ci.ymlvariable中定义了同一个 变量,则该变量被 .gitlab-ci.yml中定义的变量覆盖。如上例,最终 example.yml中变量的取值为:
POSTGRES_USER:root
POSTGRES_PASSWORD:secure_password
POSTGRES_DB: $CI_ENVIRONMENT_SLUG
  • include的文件和 .gitlab-ci.yml都定义了同一个 job,则会将两个job进行合并。上例中 example.yml中production job的 enviroment url取值为 https://domain.com

此外,include还能够使用关键字template去引入.gitlab-ci.yml模板,更为详细的信息能够阅读官方文档。gitlab

Extends指令

Func:extends替代了?YAML Anchors,可读性好,并且更加灵活。它定义一个可让job去继承的模板,这样可让咱们把一些共同的key进行抽象,方便之后的维护与扩展。ui

Example:url

.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches

rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC

Result:spa

rspec:
  script: rake rspec
  stage: test
  only:
    refs:
      - branches
    variables:
      - $RSPEC

以上是官方给的例子:tests做为模板,rspec去继承它,若是两者都有相同的key,则使用子类的value覆盖父类。.net

extend相关详细的信息请阅读:?gitlab-ci extends

include and extends结合使用

includeextends支持一块儿使用。若是只有include,仅能让某个项目引用某个YAML文件,而后根据调解触发对应的job,而加入extend后,咱们能够把一些公共属性或者方法(主要是Script)也进行统一管理。这让咱们能够更好地去抽象与统一维护。

Example:

  • B.yml
variables:
  TEST_VAR: B
  
.template:
  stage: test
  only: 
    - master
  script:
    - echo_hello
    - echo "VAR1 = ${VAR1}"
    - echo "VAR2 = ${VAR2}"
    - echo "TEST_VAR =  ${TEST_VAR}"
  • .gitlab-ci.yml
variables:
  TEST_VAR: A
  
include:
  - B.yml

job_a:
  before_script:
    - |
      function echo_hello(){
          echo "hello world!"
      }
    - VAR1="hello"
    - VAR2="world"
  extends: .template
  only:
    variables:
     - $A

master分支更新或定义了A变量时,触发CI,执行结果:

hello world!
VAR1 = hello
VAR2 = world
TEST_VAR = A

以上结果代表:

  1. .gitlab-ci.yml中执行的job,使用的环境变量是 .gitlab-ci.yml文件定义的变量,故输出 TEST_VAR = A
  2. extends的动做早于 before_script

Summary

咱们在作持续集成的时候应该仔细思考哪些东西能够用到includeextends,这样能够提升CI/CD的扩展性与可维护性。

原文地址: https://www.jianshu.com/u/bab0045ed734


你可能还喜欢


本文分享自微信公众号 - 云原生生态圈(CloudNativeEcoSystem)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索