GitlabCI学习笔记之五:GitLabRunner pipeline语法之cache

简介: GitlabCI学习笔记之五:GitLabRunner pipeline语法之cache

阅读目录

回到顶部

cache 缓存

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

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

1.cache:paths

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

$CI_PROJECT_DIR 项目目录

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

build:

 script: test

 cache:

   paths:

     - target/*.jar

如果job中定义,则会覆盖全局定cache:paths。以下实例将缓存binaries目录。

cache:
  paths:
    - my/files
build:
  script: echo "hello"
  cache:
    key: build
    paths:
      - target/

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

2.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

3.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 ...

4.综合示例:全局缓存

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"

Pipeline日志分析

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

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

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

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

5.综合示例:控制缓存策略

例如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         #此时流水线会报错,应用设置了缓存策略为pull,也就是不下载缓存,target目录是第一次运行后缓存生成的,如果不下载则目录不存在cat命令会报错
    - 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   #不下载缓存,因为build节点就是生成缓存的,实际使用过程中应当禁止下载缓存
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"
相关文章
|
Cloud Native Linux 虚拟化
如何安装和使用Docker?
如何安装和使用Docker?
835 0
|
开发者 Docker 容器
DockerFile的ADD和COPY的区别
DockerFile的ADD和COPY的区别
5700 0
|
XML 存储 JSON
GitlabCI学习笔记之五:GitLabRunner pipeline语法之artifacts dependencies
GitlabCI学习笔记之五:GitLabRunner pipeline语法之artifacts dependencies
|
7月前
|
存储 关系型数据库 调度
|
缓存 Kubernetes Docker
GitLab Runner 全面解析:Kubernetes 环境下的应用
GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式(如 Shell、Docker、Kubernetes),可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法,重点探讨了流水线缓存(以 Python 项目为例)和构建镜像的应用,特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建,能够显著提升 CI/CD 流水线的效率和可靠性,助力开发团队实现持续集成与交付的目标。
|
存储 对象存储 Swift
Ceph Reef(18.2.X)之对象访问策略配置
这篇文章讲述了对象存储的多种访问方式,包括HTTP、S3cmd、Swift和Python程序访问,并介绍了如何定制存储桶的访问策略和跨域规则。
465 8
Ceph Reef(18.2.X)之对象访问策略配置
|
消息中间件 RocketMQ
2024最全RocketMQ集群方案汇总
在研究RocketMQ集群方案时,发现网上存在诸多不一致之处,如组件包含NameServer、Broker、Proxy等。通过查阅官方文档,了解到v4.x和v5.x版本的差异。v4.x部署模式包括单主、多主、多主多从(异步复制、同步双写),而v5.x新增Local与Cluster模式,主要区别在于Broker和Proxy是否同进程部署。Local模式适合平滑升级,Cluster模式适合高可用需求。不同模式下,集群部署方案大致相同,涵盖单主、多主、多主多从等模式,以满足不同的高可用性和性能需求。
2088 0
|
Kubernetes 监控 数据可视化
k8s学习--使用argo-rollouts实现金丝雀发布
k8s学习--使用argo-rollouts实现金丝雀发布
1163 1
|
开发工具 git
GitlabCI学习笔记之四:GitLabRunner pipeline语法之only except rules workflow
GitlabCI学习笔记之四:GitLabRunner pipeline语法之only except rules workflow
|
存储 JSON Go
Golang String字符串类型转Json格式
go的string字符串格式转json格式 确实有点麻烦,如果不知道json里面的类型好像就构建不了结构体了。
3072 0