GitLab CI语法 [needs|include|extends|trigger]

root
233
文章
0
评论
2020年7月29日01:28:01 评论 3931字阅读13分6秒

GitLab CI语法 [needs|include|extends|trigger]

needs/include/extends/trigger

needs 阶段并行

可无序执行作业,无需按照阶段顺序运行某些作业,可以让多个阶段同时运行。

如果needs;设置为指向因only/except规则而未实例化的作业,或者不存在,则创建管道时会出现YML错误。

可以用needs进行绑定作业,比如build-a完成了一直可以进行build-a测试,无需等待

stages:
  - build
  - test
  - deploy

module-a-build:
  stage: build
  script: 
    - echo "hello3a"
    - sleep 10
    
module-b-build:
  stage: build
  script: 
    - echo "hello3b"
    - sleep 10

module-a-test:
  stage: test
  script: 
    - echo "hello3a"
    - sleep 10
  needs: ["module-a-build"]
    
module-b-test:
  stage: test
  script: 
    - echo "hello3b"
    - sleep 10
  needs: ["module-b-build"]
    

暂时限制了作业在needs:可能需要的最大作业数分配,ci_dag_limit_needs功能标志已启用(默认)分配10个,如果功能被禁用为50。

Feature::disable(:ci_dag_limit_needs)   # 50
Feature::enable(:ci_dag_limit_needs)  #10

制品下载

在使用needs,可通过artifacts: trueartifacts: false来控制工件下载。 默认不指定为true。

module-a-test:
  stage: test
  script: 
    - echo "hello3a"
    - sleep 10
  needs: 
    - job: "module-a-build"
      artifacts: true    ##在needs里和dependencies效果一样

相同项目中的管道制品下载,通过将project关键字设置为当前项目的名称,并指定引用,可以使用needs从当前项目的不同管道中下载工件。在下面的示例中,build_job将使用other-refref下载最新成功的build-1作业的工件:

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: group/same-project-name
      job: build-1
      ref: other-ref
      artifacts: true

 

include

可以允许引入外部YAML文件,文件具有扩展名.yml.yaml 。使用合并功能可以自定义和覆盖包含本地定义的CI / CD配置。相同的job会合并,参数值以源文件为准。

incloud:local  映入同一项目的配置文件

引入同一存储库中的文件,使用相对于根目录的完整路径进行引用,与配置文件在同一分支上使用。

ci/localci.yml: 定义一个作业用于发布。

stages:
  - deploy
  
deployjob:
  stage: deploy
  script:
    - echo 'deploy'

.gitlab-ci.yml 引入本地的CI文件'ci/localci.yml'。

include:
  local: 'ci/localci.yml'   #这个引用localci.yml必须在同一个分支,ci目录的位置是从根目录开始
  

stages:
  - build
  - test
  - deploy
  

buildjob:
  stage: build
  script: ls
  
 
testjob:
  stage: test
  script: ls

效果:

注意点:

假如本地定义了一个job为build,incloud:local里的配置文件里也定义了build阶段,就会出现重复,一般情况是源*.yml文件会去覆盖引用的*.yml文件阶段,

incloud:file  引用不同项目的配置文件

包含来自另一个项目的文件

include:
  - project: demo/demo-java-service   ##项目名称
    ref: master  ##项目分支
    file: '.gitlab-ci.yml'  ##引用文件名称

 

incloud :template  引入官方模板文件

只能使用官方提供的模板 https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates

include:
  - template: Auto-DevOps.gitlab-ci.yml

 

incloud:remote 

用于通过HTTP / HTTPS包含来自其他位置的文件,并使用完整URL进行引用. 远程文件必须可以通过简单的GET请求公开访问,因为不支持远程URL中的身份验证架构。

include:
  - remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'

要使用这种方式下载文件,需要找到对的文件地址,获取文件地址的正确方式

extends

继承模板作业,就是在.gitlab-ci.yml文件里,引用了继承a.yml文件,a文件里有的标签,.gitlab-ci.yml里也有,就不会被覆盖还是使用.gitlab-ci.yml的标签,如果a里有你没有的标签,就会被继承过来使用

stages:
  - test
variables:
  RSPEC: 'test'

.tests:
  script: echo "mvn test"
  stage: test
  only:
    refs:
      - branches
testjob:
  extends: .tests
  script: echo "mvn clean test"
  only:
    variables:
      - $RSPEC

这两个文件最好继承过来的样子

testjob:
  stage: test
  script: mvn clean test
  only:
    variables:
      - $RSPEC
    refs:
      - branches

extends & include

extends是合并相同项目下,*.yml文件里定义的job内容的

include是引用相同or不同or不同地址下*.yml文件的

localci.yml

deployjob:
  stage: deploy
  script:
    - echo 'deploy'
  only:
    - dev

.template:
  stage: build
  script: 
    - echo "build"
  only:
    - master
include:
  local: 'ci/localci.yml'

stages:
  - test
  - build 
  - deploy
  
variables:
  RSPEC: 'test'

.tests:
  script: echo "mvn test"
  stage: test
  only:
    refs:
      - branches

testjob:
  extends: .tests
  script: echo "mvn clean test"
  only:
    variables:
      - $RSPEC
      

newbuildjob:
  script:
    - echo "123"
  extends:  .template

这将运行名为useTemplate的作业,该作业运行echo Hello!.template作业中所定义,并使用本地作业中所定义的alpine Docker映像.

trigger 管道触发

当GitLab从trigger定义创建的作业启动时,将创建一个下游管道。允许创建多项目管道和子管道。triggerwhen:manual一起使用会导致错误。

多项目管道: 跨多个项目设置流水线,以便一个项目中的管道可以触发另一个项目中的管道。跨多个项目的一个.gitlab-ci.yml文件[微服务架构]

父子管道: 在同一项目中管道可以触发一组同时运行的子管道,子管道仍然按照阶段顺序执行其每个作业,但是可以自由地继续执行各个阶段,而不必等待父管道中无关的作业完成。

多项目管道

当前面阶段运行完成后,触发demo/demo-java-service项目master流水线。创建上游管道的用户需要具有对下游项目的访问权限。如果发现下游项目用户没有访问权限以在其中创建管道,则staging作业将被标记为失败

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: 
    project: demo/demo-java-service
    branch: master
    strategy: depend

project关键字,用于指定下游项目的完整路径。branch关键字指定由指定的项目分支的名称。使用variables关键字将变量传递到下游管道。 全局变量也会传递给下游项目。上游管道优先于下游管道。如果在上游和下游项目中定义了两个具有相同名称的变量,则在上游项目中定义的变量将优先。默认情况下,一旦创建下游管道,trigger作业就会以success状态完成。strategy: depend自身状态从触发的管道合并到源作业。

上游项目触发下游项目

在此示例中,一旦创建了下游管道,该staging将被标记为成功。

父子管道 【要在一个项目里面】

创建子管道ci/child01.yml

stages:
  - build

child-a-build:
  stage: build
  script: 
    - echo "hello3a"
    - sleep 10

在父管道触发子管道

staging2:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: 
    include: ci/child01.yml  
    strategy: depend

 

 

 

 

 

 

继续阅读
weinxin
我的微信
这是我的微信扫一扫
  • 文本由 发表于 2020年7月29日01:28:01
  • 除非特殊声明,本站文章均为原创,转载请务必保留本文链接
GitLab开发工作流程 Gitlab

GitLab开发工作流程

GitLab开发工作流程 特效分支开发 1.基于master主干分支创建版本分支 (release-1.1.1) 2.基于master分支创建特性分支(feature-1,feature-2.。。。)...
GitLab CI语法 [cache|artifacts|dependencies] Gitlab

GitLab CI语法 [cache|artifacts|dependencies]

GitLab CI语法   cache 【缓存文件或者目录,不建议缓存制品】 用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径。不要使用缓存在阶段之间传递工件,因为缓...
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: