4.3 使用缓存加速构建

GitLab CI/CD提供了一种缓存机制，可用于在作业运行时节省时间。

缓存是指通过重用先前作业的相同内容来加快执行作业的时间。当您开发依赖于在构建期间通过Internet获取的其他库的软件时，此功能特别有用。

如果启用了缓存，则默认情况下，从GitLab 9.0开始，它在项目级别的作业之间共享。缓存不在项目之间共享。

[info]不要使用缓存在阶段之间传递工件，因为缓存旨在存储编译项目所需的运行时依赖项。另外，缓存定义的路径是相对于项目目录，并且无法链接到其外部的文件。

在管道中使用同一 Runner，是将该缓存传递到后续阶段或管道的最简单，最有效的方法。

从Runner 的角度来看，为了使缓存有效运行，必须满足以下条件之一：

• 使用同一个 Runner
• 使用分布式缓存的Runner（缓存存储在 S3 存储桶中）
• 使用相同体系结构的多个Runner 使用 NFS 共享存储缓存

1. Java 项目缓存示例

stages:
  - build
build:
  stage: build
  image: harbor.xiodi.cn/tools/openjdk:11.0.6
  tags:
    - docker
    - host20133-docker
  variables:
    MAVEN_OPTS: "-Dmaven.repo.local=.m2"
  script:
    - chmod +x ./mvnw && ./mvnw package
  cache:
    paths:
      - .m2

2. 在特定作业上禁用缓存

如果已全局定义了缓存，则意味着每个作业将使用相同的定义。如果要想对某个作业禁用缓存，可以使用空哈希

job:
  cache: {}

3. 缓存的可用性

缓存是一种优化，但不能保证始终有效，因此您需要准备好在需要它们的每个作业中重新生成所有缓存的文件。

3.1 缓存的存储位置

$ ls /var/lib/docker/volumes/runner-6fzqvskx-project-1-concurrent-0-cache-3c3f060a0374fc8bc39395164f415a70/_data/edu-java-demo/edu-java-spring/
default
$ ls /var/lib/docker/volumes/runner-6fzqvskx-project-1-concurrent-0-cache-3c3f060a0374fc8bc39395164f415a70/_data/edu-java-demo/edu-java-spring/default/
cache.zip

3.2 缓存的压缩和解压

在最简单的情况下，请考虑仅使用安装了Runner的一台计算机，并且项目的所有作业都在同一主机上运行。缓存默认压缩为 cache.zip。

stages:
  - test
  - build
test:
  stage: test
  image: harbor.xiodi.cn/tools/openjdk:11.0.6
  tags:
    - docker
    - host20133-docker
  variables:
    MAVEN_OPTS: "-Dmaven.repo.local=.m2"
  script:
    - chmod +x ./mvnw && ./mvnw test
  cache:
    key: maven-repo-cache
    paths:
      - .m2
build:
  stage: build
  image: harbor.xiodi.cn/tools/openjdk:11.0.6
  tags:
    - docker
    - host20133-docker
  variables:
    MAVEN_OPTS: "-Dmaven.repo.local=.m2"
  script:
    - chmod +x ./mvnw && ./mvnw package
  cache:
    key: maven-repo-cache
    paths:
      - .m2

通过在单台主机上使用的单个 Runner，确保了缓存的可用性，否则，可能就没有可用的缓存。

在缓存的过程中，还需要考虑以下几点：

• 具有相同缓存 key 的作业其缓存将会被覆盖，不管路径是否相同。
• 从缓存压缩包中提取到作业的工作目录中，而 Runner 不在乎缓存是否被覆盖。

3.3 缓存不匹配

下表列举出了缓存不匹配的一些原因和一些解决方法。

//例1：

stages:
  - build
  - test
job A:
  stage: build
  tags:
    - docker
  script:
    - ls -a
    - if [ ! -d public ]; then mkdir public && echo `date` > public/public.txt; fi
  cache:
    key: keyA
    paths:
      - public/
job B:
  stage: test
  tags:
    - docker
  script:
    - ls -a
    - if [ ! -d vendor ]; then mkdir vendor && echo `date` > vendor/vendor.txt; fi
  cache:
    key: keyA
    paths:
      - vendor/

运行的流程:

• job A 运行
• public/ 目录被缓存为 cache.zip
• job B 运行
• 如果先前有缓存，则解压
• vendor/ 被缓存为 ceche.zip 并覆盖前一个
• 下次 job A 运行时，它将使用 job B 的缓存，因此缓存无效

要解决此问题，请设置相同的路径和 key

在另一种情况下，如果您为项目分配了多个执行器，但又没有启用分布式缓存，即使使用相同的 key，也不会进行覆盖。

4. 清除缓存

清除缓存的方法有两种：

• 通过更改清除缓存
• 手动清除缓存

4.1 通过更改清除缓存

在 .gitlab-ci.yml 中设置一个 cache.key，进行覆盖清除

4.2 手动清除缓存