GitLab CI语法 [cache|artifacts|dependencies]

root
233
文章
0
评论
2020年7月28日14:41:23 评论 9449字阅读31分29秒

GitLab CI语法 [cache|artifacts|dependencies]

 

cache 【缓存文件或者目录,不建议缓存制品】

用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径。不要使用缓存在阶段之间传递工件,因为缓存旨在存储编译项目所需的运行时依赖项。

如果在job范围之外定义了cache ,则意味着它是全局设置,所有job都将使用该定义。如果未全局定义或未按job定义则禁用该功能。

cache:paths

使用paths指令选择要缓存的文件或目录,路径是相对于项目目录,不能直接链接到项目目录之外。

$CI_PROJECT_DIR 项目目录

在job build中定义缓存,将会缓存target目录下的所有.jar文件。

build:
  script: test
  cache:
    paths:
      - target/*.jar

当在全局定义了cache:paths会被job中覆盖。所有的项目在引用这个缓存的时候就会把target/*.jar文件不断覆盖

cache:
  paths:
    - my/files

build:
  script: echo "hello"
  cache:
    key: build  ##指定作业
    paths:
      - target/

由于缓存是在job之间共享的,如果不同的job使用不同的路径就出现了缓存覆盖的问题。如何让不同的job缓存不同的cache呢?设置不同的cache:key

cache:key 缓存标记

为缓存做个标记,可以配置job、分支为key来实现分支、作业特定的缓存。为不同 job 定义了不同的 cache:key 时, 会为每个 job 分配一个独立的 cache。cache:key变量可以使用任何预定义变量,默认default ,从GitLab 9.0开始,默认情况下所有内容都在管道和作业之间共享。

按照分支设置缓存

cache:
    key: ${CI_COMMIT_REF_SLUG}

files: 文件发生变化自动重新生成缓存(files最多指定两个文件),提交的时候检查指定的文件。

根据指定的文件生成密钥计算SHA校验和,如果文件未改变值为default。

cache:
    key:
        files:
          - Gemfile.lock
          - package.json
     paths:
        - vendor/ruby
        - node_modules

prefix: 允许给定prefix的值与指定文件生成的秘钥组合。

在这里定义了全局的cache,如果文件发生变化则值为 rspec-xxx111111111222222 ,未发生变化为rspec-default。

cache:
  key:
    files:
      - Gemfile.lock
    prefix: ${CI_JOB_NAME}
  paths:
    - vendor/ruby

rspec:
  script:
    - bundle exec rspec

 

例如,添加$CI_JOB_NAME prefix将使密钥看起来像: rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5 ,并且作业缓存在不同分支之间共享,如果分支更改了Gemfile.lock ,则该分支将为cache:key:files具有新的SHA校验和. 将生成一个新的缓存密钥,并为该密钥创建一个新的缓存. 如果Gemfile.lock未发生变化 ,则将前缀添加default ,因此示例中的键为rspec-default

stages:
  - setup
  - test

prepare:
  stage: setup
  cache:
    key: gems
    paths:
      - vendor/bundle
  script:
    - bundle install --deployment

rspec:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - bundle exec rspec ...

cache:policy 策略

默认:在执行开始时下载文件,并在结束时重新上传文件。称为" pull-push缓存策略.

policy: pull 跳过下载步骤

policy: push 跳过上传步骤

stages:
  - setup
  - test

prepare:
  stage: setup
  cache:
    key: gems
    paths:
      - vendor/bundle
  script:
    - bundle install --deployment

rspec:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - bundle exec rspec ...

 

综合实例(一) 全局缓存

before_script:
  - echo "before-script!!"

variables:
  DOMAIN: example.com

cache: 
  paths:
   - target/

stages:
  - build
  - test
  - deploy
  
build:
  before_script:
    - echo "before-script in job"
  stage: build
  tags:
    - build
  only:
    - master
  script:
    - ls
    - id
    - mvn clean package -DskipTests
    - ls target
    - echo "$DOMAIN"
    - false && true ; exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;
    - sleep 2;
  after_script:
    - echo "after script in job"


unittest:
  stage: test
  tags:
    - build
  only:
    - master
  script:
    - echo "run test"
    - echo 'test' >> target/a.txt
    - ls target
  retry:
    max: 2
    when:
      - script_failure
  
deploy:
  stage: deploy
  tags:
    - build
  only:
    - master
  script:
    - echo "run deploy"
    - ls target
  retry:
    max: 2
    when:
      - script_failure
      

after_script:
  - echo "after-script"

执行流水线,日志分析

build作业运行时会对项目代码打包,然后生成target目录。作业结束创建缓存。

开始第二个作业test,此时会把当前目录中的target目录删除掉(因为做了git 对比)。

获取到第一个作业生成的缓存target目录。

开始第三个作业,同样先删除了target目录,然后获取了第二个作业的缓存。最后生成了当前的缓存。

可以看出这种全局缓存,下一个任务会使用上一个任务的缓存

结论: 全局缓存生效于未在作业中定义缓存的所有作业,这种情况如果每个作业都对缓存目录做了更改,会出现缓存被覆盖的场景。

综合实例(二)

控制缓存策略

例如build阶段我们需要生成新的target目录内容,可以优化设置job运行时不下载缓存。

before_script:
  - echo "before-script!!"

variables:
  DOMAIN: example.com

cache: 
  paths:
   - target/

stages:
  - build
  - test
  - deploy
  
build:
  before_script:
    - echo "before-script in job"
  stage: build
  tags:
    - build
  only:
    - master
  script:
    - ls
    - id
    - cat target/a.txt
    - mvn clean package -DskipTests
    - ls target
    - echo "$DOMAIN"
    - false && true ; exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;
    - sleep 2;
  after_script:
    - echo "after script in job"
  cache:
    policy: pull   #不下载缓存


unittest:
  stage: test
  tags:
    - build
  only:
    - master
  script:
    - echo "run test"
    - echo 'test' >> target/a.txt
    - ls target
    - cat target/a.txt
  retry:
    max: 2
    when:
      - script_failure
  
deploy:
  stage: deploy
  tags:
    - build
  only:
    - master
  script:
    - cat target/a.txt
    - echo "run deploy"
    - ls target
    - echo "deploy" >> target/a.txt
  retry:
    max: 2
    when:
      - script_failure
      

after_script:
  - echo "after-script"
  

artifacts 生成制品

用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。作业完成后,工件将被发送到GitLab,并可在GitLab UI中下载。

artifacts:paths

路径是相对于项目目录的,不能直接链接到项目目录之外

将制品设置为target目录【可以是文件,包,目录】

artifacts:
  paths:
    - target/

收集好的制品就可以在gitlab里进行展示

制品的创建

default-job:
  script:
    - mvn test -U
  except:
    - tags

release-job:
  script:
    - mvn package -U
  artifacts:
    paths:
      - target/*.war
  only:
    - tags

artifacts:expose_as,【定义展示包的名称】

关键字expose_as可用于在合并请求 UI中公开作业工件。最多个数是10个

例如,要匹配单个文件:

test:
  script: 
    - echo 1
  artifacts:
    expose_as: 'artifact 1'   ##制品的名称
    paths: 
      - path/to/file.txt   ##制品的路径

使用此配置,GitLab将在指向的相关合并请求中添加链接file1.txt

制品浏览

请注意以下几点:

  • 每个合并请求最多可以公开10个作业工件。

  • 如果指定了目录,那么如果目录中有多个文件,则该链接将指向指向作业工件浏览器。

  • 如果开启GitlabPages可以对.html .htm .txt .json .log扩展名单个文件工件渲染工件。

artifacts:name

通过name指令定义所创建的工件存档的名称。可以为每个存档使用唯一的名称。 artifacts:name变量可以使用任何预定义变量。默认名称是artifacts,下载artifacts改为artifacts.zip

使用当前作业的名称创建存档

job:
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - binaries/

使用内部分支或标记的名称(仅包括binaries目录)创建存档,

job:
  artifacts:
    name: "$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

使用当前作业的名称和当前分支或标记(仅包括二进制文件目录)创建存档

job:
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

要创建一个具有当前阶段名称和分支名称的存档

job:
  artifacts:
    name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

 

artifacts:when

用于在作业失败时或尽管失败而上传工件。on_success仅在作业成功时上载工件。这是默认值。on_failure仅在作业失败时上载工件always 上载工件,无论作业状态如何。

要仅在作业失败时上传工件:

job:
  artifacts:
    when: on_failure

artifacts:expire_in

制品的有效期,从上传和存储到GitLab的时间开始算起。如果未定义过期时间,则默认为30天。

expire_in的值以单位的经过时间,除非提供了单位。可解析值的示例:

‘42’##42秒
‘3 mins 4 sec’
‘2 hrs 20 min’
‘2h20min’
‘6 mos 1 day’
‘47 yrs 6 mos and 4d’
‘3 weeks and 2 days’

一周后过期

job:
  artifacts:
    expire_in: 1 week

artifacts:reports【junit单元测试报告,cobertura覆盖率报告】

用于从作业中收集测试报告,代码质量报告安全报告. 在GitLab的UI中显示这些报告。

注意:无论作业结果(成功或失败),都将收集测试报告。

artifacts:reports:junit ------单元测试报告

收集junit单元测试报告,收集的JUnit报告将作为工件上传到GitLab,并将自动显示在合并请求中。

单元测试这个功能gitlab默认是关闭的,要想使用这个功能需要手动进入gitlab控制台进行开启

build:
  stage: build
  tags:
    - build
  only:
    - master
  script:
    - mvn test
    - mvn cobertura:cobertura
    - ls target
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    when: on_success
    expose_as: 'artifact 1'
    paths:
      - target/*.jar
    reports:
      junit: target/surefire-reports/TEST-*.xml

注意:如果您使用的JUnit工具导出到多个XML文件,则可以在一个作业中指定多个测试报告路径,它们将被自动串联到一个文件中. 使用文件名模式( junit: rspec-*.xml ),文件名数组( junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml] )或其组合( junit: [rspec.xml, test-results/TEST-*.xml] )。

开启单元测试以后,带分支合并请求的时候就会有测试的数据,失败也会显示出来

开启gitlab单元测试

登录gitlab
su -  git
$ gitlab-rails console
--------------------------------------------------------------------------------
 GitLab:       12.9.0 (9a382ff2c82) FOSS
 GitLab Shell: 12.0.0
 PostgreSQL:   10.12
--------------------------------------------------------------------------------
Feature.enable(:junit_pipeline_view)Loading production environment (Rails 6.0.2)
irb(main):001:0>
irb(main):002:0>
irb(main):003:0> Feature.enable(:junit_pipeline_view)
=> true
irb(main):004:0>

artifacts:reports:cobertura-------覆盖率报告--一般不使用了解即可

cobertura是mvn里的一个插件

收集的Cobertura覆盖率报告将作为工件上传到GitLab,并在合并请求中自动显示。

build:
  stage: build
  tags:
    - build
  only:
    - master
  script:
    - mvn test
    - mvn cobertura:cobertura
    - ls target
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    when: on_success
    expose_as: 'artifact 1'
    paths:
      - target/*.jar
    reports:
      junit: target/surefire-reports/TEST-*.xml
      cobertura: target/site/cobertura/coverage.xml

要使用cobertura也需要在gitlab控制台进行开启功能

$ gitlab-rails console
--------------------------------------------------------------------------------
 GitLab:       12.9.0 (9a382ff2c82) FOSS
 GitLab Shell: 12.0.0
 PostgreSQL:   10.12
--------------------------------------------------------------------------------


Loading production environment (Rails 6.0.2)
irb(main):001:0>
irb(main):002:0>
irb(main):003:0> Feature.enable(:coverage_report_view)
=> true

maven集成cobertura插件

<plugins>       
  <!--  cobertura plugin start -->
  <plugin>
    <groupId>org.codehaus.mojo</groupId>  
    <artifactId>cobertura-maven-plugin</artifactId>  
    <version>2.7</version>  
    <configuration>  
      <formats>  
          <format>html</format>  
          <format>xml</format>  
      </formats>  
  	</configuration>  
  </plugin>       
  <!--  cobertura plugin end -->

</plugins>

执行 mvn cobertura:cobertura 运行测试并产生 Cobertura 覆盖率报告。

before_script:
  - echo "before-script!!"

variables:
  DOMAIN: example.com


cache: 
  paths:
   - target/

stages:
  - build
  - test
  - deploy
  
build:
  before_script:
    - echo "before-script in job"
  stage: build
  tags:
    - build
  only:
    - master
  script:
    - ls
    - id
    - mvn test
    - mvn cobertura:cobertura
    - ls target
    - echo "$DOMAIN"
    - false && true ; exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;
    - sleep 2;
  after_script:
    - echo "after script in job"
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    when: on_success
    #expose_as: 'artifact 1'
    paths:
      - target/*.jar
      #- target/surefire-reports/TEST*.xml
    reports:
      junit: target/surefire-reports/TEST-*.xml
      cobertura: target/site/cobertura/coverage.xml
  coverage: '/Code coverage: \d+\.\d+/'


unittest:
  dependencies:
    - build
  stage: test
  tags:
    - build
  only:
    - master
  script:
    - echo "run test"
    - echo 'test' >> target/a.txt
    - ls target
  retry:
    max: 2
    when:
      - script_failure
  
deploy:
  stage: deploy
  tags:
    - build
  only:
    - master
  script:
    - echo "run deploy"
    - ls target
  retry:
    max: 2
    when:
      - script_failure
      
      

after_script:
  - echo "after-script"
  

dependencies

定义要获取工件的作业列表,只能从当前阶段之前执行的阶段定义作业。定义一个空数组将跳过下载该作业的任何工件不会考虑先前作业的状态,因此,如果它失败或是未运行的手动作业,则不会发生错误。

unittest:
  dependencies:
    - build
  stage: test
  tags:
    - build
  only:
    - master
  script:
    - echo "run test"
    - echo 'test' >> target/a.txt
    - ls target
  retry:
    max: 2
    when:
      - script_failure

 

 

综合实例

before_script:
  - echo "before-script!!"

variables:
  DOMAIN: example.com


cache: 
  paths:
   - target/

stages:
  - build
  - test
  - deploy
  
build:
  before_script:
    - echo "before-script in job"
  stage: build
  tags:
    - build
  only:
    - master
  script:
    - ls
    - id
    - mvn test
    - mvn cobertura:cobertura
    - ls target
    - echo "$DOMAIN"
    - false && true ; exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;
    - sleep 2;
  after_script:
    - echo "after script in job"
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    when: on_success
    #expose_as: 'artifact 1'
    paths:
      - target/*.jar
      #- target/surefire-reports/TEST*.xml
    reports:
      junit: target/surefire-reports/TEST-*.xml
      cobertura: target/site/cobertura/coverage.xml
  coverage: '/Code coverage: \d+\.\d+/'


unittest:
  dependencies:
    - build
  stage: test
  tags:
    - build
  only:
    - master
  script:
    - echo "run test"
    - echo 'test' >> target/a.txt
    - ls target
  retry:
    max: 2
    when:
      - script_failure
  
deploy:
  stage: deploy
  tags:
    - build
  only:
    - master
  script:
    - echo "run deploy"
    - ls target
  retry:
    max: 2
    when:
      - script_failure
      
      

after_script:
  - echo "after-script"
  

dependencies

 

 

 

 

 

 

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

GitLab开发工作流程

GitLab开发工作流程 特效分支开发 1.基于master主干分支创建版本分支 (release-1.1.1) 2.基于master分支创建特性分支(feature-1,feature-2.。。。)...
匿名

发表评论

匿名网友 填写信息

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