GitLab CI/CD의 캐싱

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

캐시는 작업이 다운로드하고 저장하는 하나 이상의 파일입니다. 동일한 캐시를 사용하는 이후 작업은 파일을 다시 다운로드할 필요가 없으므로 더 빨리 실행됩니다.

.gitlab-ci.yml 파일에서 캐시를 정의하는 방법은 캐시 참조를 참조하세요.

캐시와 아티팩트의 차이점

캐시는 인터넷에서 다운로드한 패키지와 같은 종속 항목에 사용합니다. 캐시는 GitLab Runner가 설치된 곳에 저장되며 분산 캐시가 활성화된 경우 S3에 업로드됩니다.

아티팩트는 단계 간에 중간 빌드 결과를 전달하는 데 사용합니다. 아티팩트는 작업에 의해 생성되며 GitLab에 저장되어 다운로드할 수 있습니다.

아티팩트와 캐시는 프로젝트 디렉터리를 기준으로 경로를 정의하며, 프로젝트 디렉터리 외부의 파일에 연결할 수 없습니다.

캐시

  • cache 키워드를 사용하여 작업당 캐시를 정의합니다. 그렇지 않으면 비활성화됩니다.
  • 이후 파이프라인에서 캐시를 사용할 수 있습니다.
  • 동일한 파이프라인의 이후 작업은 종속 항목이 동일한 경우 캐시를 사용할 수 있습니다.
  • 다른 프로젝트는 캐시를 공유할 수 없습니다.
  • 기본적으로 보호 및 비보호 브랜치는 캐시를 공유하지 않습니다. 그러나 이 동작을 변경할 수 있습니다.

아티팩트

  • 작업당 아티팩트를 정의합니다.
  • 동일 파이프라인의 후속 작업은 아티팩트를 사용할 수 있습니다.
  • 다른 프로젝트는 아티팩트를 공유할 수 없습니다.
  • 기본적으로 아티팩트는 30일 후에 만료됩니다. 사용자 정의 만료 시간을 정의할 수 있습니다.
  • 최신 아티팩트는 최신 성공적인 작업의 아티팩트를 유지할 경우에만 만료되지 않습니다.
  • 종속 항목을 사용하여 어떤 작업이 아티팩트를 가져올지 제어합니다.

좋은 캐싱 관행

캐시의 최대 가용성을 보장하려면 다음 중 하나 이상을 수행하세요:

  • Runner에 태그를 지정하고 해당 태그를 공유하는 작업에서 사용하세요.
  • 특정 프로젝트에서만 사용 가능한 러너를 사용하세요.](../runners/runners_scope.md#prevent-a-project-runner-from-being-enabled-for-other-projects)
  • 워크플로에 맞는 key를 사용하세요. 예를 들어 각 브랜치에 대해 다른 캐시를 구성할 수 있습니다.

캐시를 효율적으로 사용하려면 러너를 다음 중 하나로 설정해야합니다:

  • 모든 작업에 단일 러너를 사용합니다.
  • 분산 캐싱을 갖는 여러 러너를 사용합니다. 캐시는 S3 버킷에 저장됩니다. GitLab.com의 인스턴스 러너는 이 방식으로 작동합니다. 이러한 러너는 자동 확장 모드에 있을 수 있지만 그럴 필요는 없습니다. 캐시 개체를 관리하려면 수명주기 규칙을 적용하여 일정 시간이 지난 후 캐시 개체를 삭제하세요. 수명주기 규칙은 개체 저장소 서버에서 사용할 수 있습니다.
  • 동일한 아키텍처를 갖는 여러 러너를 사용하고 이러한 러너는 캐시를 저장하기 위한 공통 네트워크 마운트 디렉터리를 공유합니다. 이 디렉터리에는 NFS나 유사한 것을 사용해야합니다. 이러한 러너는 자동 확장 모드에 있어야합니다.

여러 캐시 사용

최대 네 개의 캐시를 가질 수 있습니다: 

test-job:
  stage: build
  cache:
    - key:
        files:
          - Gemfile.lock
      paths:
        - vendor/ruby
    - key:
        files:
          - yarn.lock
      paths:
        - .yarn-cache/
  script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install
    - yarn install --cache-folder .yarn-cache
    - echo Run tests...

여러 캐시를 사용할 경우 대체 캐시 키로 결합하면 전역 대체 캐시가 캐시를 찾지 못할 때마다 가져옵니다.

대체 캐시 키 사용

캐시 키별 대체

각 캐시 항목은 fallback_keys 키워드로 최대 다섯 개의 대체 키를 지원합니다. 작업이 캐시 키를 찾지 못하면 작업은 대신 대체 캐시를 가져오려고 시도합니다. 대체 키는 순서대로 검색되며 캐시가 발견될 때까지 계속합니다. 캐시가 없는 경우 작업은 캐시를 사용하지 않고 실행됩니다. 예: 

test-job:
  stage: build
  cache:
    - key: cache-$CI_COMMIT_REF_SLUG
      fallback_keys:
        - cache-$CI_DEFAULT_BRANCH
        - cache-default
      paths:
        - vendor/ruby
  script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install
    - echo Run tests...

이 예에서:

  1. 작업은 cache-$CI_COMMIT_REF_SLUG 캐시를 찾습니다.
  2. cache-$CI_COMMIT_REF_SLUG를 찾을 수 없으면 작업은 대체 옵션으로서 cache-$CI_DEFAULT_BRANCH를 찾습니다.
  3. cache-$CI_DEFAULT_BRANCH를 찾을 수 없으면 작업은 두 번째 대체 옵션으로서 cache-default를 찾습니다.
  4. 아무 것도 찾을 수 없으면 작업은 새 캐시를 만들지 않고 새로운 캐시를 생성하지 않은 채로 Ruby 종속 항목을 모두 다운로드합니다. 작업이 완료되면 cache-$CI_COMMIT_REF_SLUG를 위한 새 캐시를 만듭니다.

대체 키는 cache:key와 동일한 처리 로직을 따릅니다:

전역 대체 키

[$CI_COMMIT_REF_SLUG 미리 정의된 변수](../variables/predefined_variables.md)를 사용하여 [cache:key](../yaml/index.md#cachekey)를 지정할 수 있습니다. 예를 들어, $CI_COMMIT_REF_SLUG가 test이면 작업은 test`로 태그가 지정된 캐시를 가져오도록 설정할 수 있습니다.

이 태그와 일치하는 캐시가 없는 경우 CACHE_FALLBACK_KEY를 사용하여 존재하지 않을 때 사용할 캐시를 지정할 수 있습니다.

다음 예에서, $CI_COMMIT_REF_SLUG가 찾을 수 없는 경우, 작업은 CACHE_FALLBACK_KEY 변수에서 정의한 키를 사용합니다: 

variables:
  CACHE_FALLBACK_KEY: fallback-key

job1:
  script:
    - echo
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - binaries/

캐시 추출 순서:

  1. cache:key를 검색합니다.
  2. fallback_keys의 각 항목에 대해 순서대로 검색합니다.
  3. CACHE_FALLBACK_KEY의 전역 대체 키를 검색합니다.

캐시 추출 프로세스는 첫 번째 성공적인 캐시를 검색한 후 중지합니다.

특정 작업에 대해 캐시 비활성화하기

전역적으로 캐시를 정의하면 모든 작업이 동일한 정의를 사용합니다. 각 작업에 대해 이 동작을 재정의할 수 있습니다.

작업 전체에서 캐시를 완전히 비활성화하려면 빈 목록을 사용하세요: 

job:
  cache: []

전역 구성 상속 및 작업별 특정 설정 재정의하기

앵커를 사용하여 전역 캐시를 덮어쓰지 않고 캐시 설정을 재정의할 수 있습니다. 예를 들어, 한 작업에서 policy를 덮어쓰고 싶다면: 

default:
  cache: &global_cache
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
      - public/
      - vendor/
    policy: pull-push

job:
  cache:
    # 모든 전체 캐시 설정 상속
    <<: *global_cache
    # 정책 덮어쓰기
    policy: pull

자세한 내용은 cache: policy를 참조하세요.

캐시의 일반적인 사용 사례

일반적으로 캐시를 사용하여 각 작업을 실행할 때 종속성이나 라이브러리와 같은 콘텐츠를 반복적으로 다운로드하는 것을 피합니다. Node.js 패키지, PHP 패키지, Ruby 젬, Python 라이브러리 등이 캐싱될 수 있습니다.

예제는 GitLab CI/CD 템플릿을 참조하세요.

동일 브랜치의 작업 간 캐시 공유

각 브랜치의 작업에서 동일한 캐시를 사용하려면 key: $CI_COMMIT_REF_SLUG를 사용하여 캐시를 정의하세요: 

cache:
  key: $CI_COMMIT_REF_SLUG

이 구성은 캐시를 실수로 덮어쓰는 것을 방지합니다. 그러나 병합 요청의 첫 번째 파이프라인은 느립니다. 브랜치로 커밋을 더 푸시하면 캐시가 재사용되어 작업이 더 빨리 실행됩니다.

작업 및 브랜치별 캐싱을 활성화하려면: 

cache:
  key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"

단계별 및 브랜치별 캐싱을 활성화하려면: 

cache:
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"

다른 브랜치의 작업 간 캐시 공유

모든 브랜치 및 작업에서 동일한 캐시를 공유하려면 모든 것에 동일한 키를 사용하세요: 

cache:
  key: one-key-to-rule-them-all

브랜치 간에 캐시를 공유하지만 각 작업에는 고유한 캐시가 있는 경우: 

cache:
  key: $CI_JOB_NAME

작업의 캐시 정책을 제어하기 위해 변수 사용하기

작업이 달라지는 유일한 차이가 pull 정책인 경우, CI/CD 변수를 사용하여 작업의 중복을 줄일 수 있습니다.

예를 들어: 

conditional-policy:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      variables:
        POLICY: pull-push
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
      variables:
        POLICY: pull
  stage: build
  cache:
    key: gems
    policy: $POLICY
    paths:
      - vendor/bundle
  script:
    - echo "이 작업은 브랜치에 따라 캐시를 가져오거나 푸시합니다."
    - echo "의존성 다운로드 중..."

이 예에서 작업의 캐시 정책은:

  • 기본 브랜치의 변경 사항에 대해 pull-push.
  • 다른 브랜치의 변경 사항에 대해 pull.

Node.js 종속성 캐시

프로젝트에서 npm을 사용하여 Node.js 종속성을 설치하는 경우, 다음 예제는 모든 작업이 상속하는 기본 cache를 정의합니다. 기본적으로 npm은 캐시 데이터를 홈 폴더 (~/.npm)에 저장합니다. 그러나 프로젝트 디렉토리 외부의 것은 캐시할 수 없습니다. 대신 npm에게 ./.npm을 사용하도록 지시하고 브랜치별로 캐시를 설정하세요: 

default:
  image: node:latest
  cache:  # 작업 간에 모듈을 캐시
    key: $CI_COMMIT_REF_SLUG
    paths:
      - .npm/
  before_script:
    - npm ci --cache .npm --prefer-offline

test_async:
  script:
    - node ./specs/start.js ./specs/async.spec.js

락 파일에서 캐시 키 계산하기

cache:key:files를 사용하여 package-lock.json이나 yarn.lock과 같은 락 파일에서 캐시 키를 계산하고 많은 작업에서 재사용할 수 있습니다. 

default:
  cache:  # 락 파일을 사용하여 모듈 캐시
    key:
      files:
        - package-lock.json
    paths:
      - .npm/

Yarn을 사용하는 경우, yarn-offline-mirror를 사용하여 node_modules tarball을 캐시할 수 있습니다. 덜 압축해야할 파일이 더 적기 때문에 캐시가 빠르게 생성됩니다. 

job:
  script:
    - echo 'yarn-offline-mirror ".yarn-cache/"' >> .yarnrc
    - echo 'yarn-offline-mirror-pruning true' >> .yarnrc
    - yarn install --frozen-lockfile --no-progress
  cache:
    key:
      files:
        - yarn.lock
    paths:
      - .yarn-cache/

PHP 종속성 캐시

프로젝트에서 Composer를 사용하여 PHP 종속성을 설치하는 경우, 다음 예제는 모든 작업이 상속하는 기본 cache를 정의합니다. PHP 라이브러리 모듈은 vendor/에 설치되며 브랜치별로 캐시됩니다: 

default:
  image: php:7.2
  cache:  # 작업 간에 라이브러리 캐시
    key: $CI_COMMIT_REF_SLUG
    paths:
      - vendor/
  before_script:
    # Composer 설치 및 실행
    - curl --show-error --silent "https://getcomposer.org/installer" | php
    - php composer.phar install

test:
  script:
    - vendor/bin/phpunit --configuration phpunit.xml --coverage-text --colors=never

Python 종속성 캐시

프로젝트에서 pip를 사용하여 Python 종속성을 설치하는 경우, 다음 예제는 모든 작업이 상속하는 기본 cache를 정의합니다. pip의 캐시는 .cache/pip/에 정의되며 브랜치별로 캐시됩니다: 

default:
  image: python:latest
  cache:                      # Pip 캐시에는 python 패키지가 저장되지 않습니다
    paths:                    # https://pip.pypa.io/en/stable/topics/caching/
      - .cache/pip
  before_script:
    - python -V               # 디버깅용 python 버전 출력
    - pip install virtualenv
    - virtualenv venv
    - source venv/bin/activate

variables:  # 로컬 항목만 캐시할 수 있기 때문에 pip 캐시 디렉토리를 프로젝트 디렉토리 내부로 변경합니다.
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

test:
  script:
    - python setup.py test
    - pip install ruff
    - ruff --format=gitlab .

Ruby 종속성 캐시

프로젝트가 Bundler를 사용하여 gem 종속성을 설치하는 경우, 다음 예제는 모든 작업이 상속하는 기본 cache를 정의합니다. Gems은 vendor/ruby/에 설치되며 브랜치별로 캐시됩니다. 

default:
  image: ruby:2.6
  cache:                                            # 빌드 간 gems 캐시
    key: $CI_COMMIT_REF_SLUG
    paths:
      - vendor/ruby
  before_script:
    - ruby -v                                       # 디버깅을 위해 ruby 버전 출력
    - bundle config set --local path 'vendor/ruby'  # 지정된 gems를 설치할 위치
    - bundle install -j $(nproc)                    # ./vendor/ruby에 종속성 설치

rspec:
  script:
    - rspec spec

다른 gems가 필요한 작업이 있는 경우 전역 cache 정의에 prefix 키워드를 사용합니다. 이 구성은 각 작업에 대해 다른 캐시를 생성합니다.

예를 들어, 테스팅 작업은 프로덕션 배포 작업과 동일한 gems가 필요하지 않을 수 있습니다. 

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

test_job:
  stage: test
  before_script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install --without production
  script:
    - bundle exec rspec

deploy_job:
  stage: production
  before_script:
    - bundle config set --local path 'vendor/ruby'   # 지정된 gems를 설치할 위치
    - bundle install --without test
  script:
    - bundle exec deploy

Go 종속성 캐시

프로젝트가 Go Modules를 사용하여 Go 종속성을 설치하는 경우, 다음 예제는 go-cache 템플릿에서 cache를 정의합니다. 모든 go 프로젝트에 대해 캐시됩니다. 

.go-cache:
  variables:
    GOPATH: $CI_PROJECT_DIR/.go
  before_script:
    - mkdir -p .go
  cache:
    paths:
      - .go/pkg/mod/

test:
  image: golang:1.13
  extends: .go-cache
  script:
    - go test ./... -v -short

캐시의 가용성

캐싱은 최적화이지만 항상 작동하는 것은 아닙니다. 필요한 모든 작업에서 캐시된 파일을 다시 생성해야 할 수 있습니다.

.gitlab-ci.yml에서 캐시를 정의한 후 캐시의 가용성은 다음에 따라 달라집니다:

  • 러너의 실행기 유형.
  • 캐시를 작업 간에 전달하기 위해 다른 러너를 사용하는지 여부.

캐시 저장 위치

작업에 대해 정의된 모든 캐시는 단일 cache.zip 파일에 아카이브됩니다. 러너 구성에 따라 파일이 저장되는 위치가 정의됩니다. 기본적으로 캐시는 GitLab Runner가 설치된 기기에 저장됩니다. 위치 또한 실행기 유형에 따라 달라집니다.

러너 실행기 캐시의 기본 경로
Shell 로컬로, gitlab-runner 사용자의 홈 디렉터리 아래: /home/gitlab-runner/cache/<user>/<project>/<cache-key>/cache.zip.
Docker 로컬로, 도커 볼륨 아래: /var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip.
Docker Machine (자동 확장 러너) Docker 실행기와 동일합니다.

작업에서 동일한 경로에 캐시 및 아티팩트를 저장하는 경우, 캐시가 덮어쓰일 수 있습니다. 캐시는 아티팩트보다 먼저 복원되기 때문입니다.

캐시 키 이름

캐시 키에 접미사가 추가되며, 전역 대체 캐시 키는 예외입니다.

예를 들어, cache.key가 $CI_COMMIT_REF_SLUG로 설정되고 main 및 feature 두 브랜치가 있다고 가정할 때, 다음 표는 생성된 캐시 키를 나타냅니다:

브랜치 이름 캐시 키
main main-protected
feature feature-non_protected
모든 브랜치에 동일한 캐시 사용

캐시 키 이름을 사용하려고 하지 않는다면, 모든 분기(보호된 및 비보호된)에서 동일한 캐시를 사용할 수 있습니다.

캐시 키 이름을 사용하지 않으려면:

  1. 왼쪽 사이드바에서 검색 또는 프로젝트로 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > CI/CD를 선택합니다.
  3. 일반 파이프라인을 확장합니다.
  4. 보호된 브랜치에 대한 별도의 캐시 사용 확인란을 선택 해제합니다.
  5. 변경 사항 저장을 선택합니다.

아카이브 및 추출 작업 방식

다음 예제는 연속된 두 단계에서 두 작업을 보여줍니다: 

stages:
  - build
  - test

default:
  cache:
    key: build-cache
    paths:
      - vendor/
  before_script:
    - echo "Hello"

job A:
  stage: build
  script:
    - mkdir vendor/
    - echo "build" > vendor/hello.txt
  after_script:
    - echo "World"

job B:
  stage: test
  script:
    - cat vendor/hello.txt

한 기기에 한 러너가 설치된 경우 프로젝트의 모든 작업이 동일한 호스트에서 실행됩니다.

  1. 파이프라인 시작.
  2. job A 실행.
  3. 캐시가 추출됨(존재하는 경우).
  4. before_script가 실행됨.
  5. script가 실행됨.
  6. after_script가 실행됨.
  7. cache 실행 및 vendor/ 디렉토리가 cache.zip로 압축됨. 그런 다음 러너 설정 및 cache: key에 따라 디렉토리에 저장됩니다.
  8. job B 실행.
  9. 캐시가 추출됨(존재하는 경우).
  10. before_script가 실행됨.
  11. script가 실행됨.
  12. 파이프라인 완료.

한 기기에서 단일 러너를 사용하면 job B가 job A와 다른 러너에서 실행될 수 있는 문제가 없습니다. 이러한 구성은 캐시가 단계 간에 재사용될 수 있도록 보장합니다. build 단계에서 test 단계로 실행이 동일한 러너/기기에서 이루어질 때만 작동합니다. 그렇지 않으면 캐시가 사용 불가능할 수 있습니다(캐시 불일치).

캐싱 프로세스 중 고려해야 할 사항도 몇 가지 있습니다:

  • 다른 캐시 구성의 다른 작업이 동일한 zip 파일에 캐시를 저장한 경우 덮어쓰입니다.
  • S3 기반 공유 캐시를 사용하는 경우, 두 작업이 다른 경로지만 동일한 캐시 키를 갖는 경우 캐시가 덮어쓰입니다.
  • cache.zip에서 캐시를 추출할 때, zip 파일의 모든 것이 작업의 작업 디렉토리(일반적으로 내려받은 저장소)에 추출되며, 러너는 job A의 아카이브가 job B의 아카이브를 덮어쓰더라도 문제가 없습니다.

단일 러너가 단일 기기에 설치되어있는 경우에는 캐시가 다르게 실행되는 것을 방지합니다. 이 설정은 캐시를 단계 간에 재사용할 수 있음을 보장합니다. build 단계에서 test 단계로 실행되는 경우에만 작동합니다. 그렇지 않으면 캐시가 사용 불가능할 수 있습니다(캐시 불일치).

캐시 지우기

런너는 기존 데이터를 재사용하여 작업을 빠르게 실행하기 위해 캐시를 사용합니다. 이는 때때로 일관성 없는 동작으로 이어질 수 있습니다.

캐시의 새로운 복사본으로 시작하는 두 가지 방법이 있습니다.

cache:key를 변경하여 캐시 지우기

.gitlab-ci.yml 파일에서 cache: key의 값을 변경합니다. 파이프라인이 다음으로 실행될 때, 캐시는 다른 위치에 저장됩니다.

캐시 수동으로 지우기

GitLab UI에서 캐시를 지울 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 빌드 > 파이프라인을 선택합니다.
  3. 우측 상단에서 런너 캐시 지우기를 선택합니다.

다음 커밋에서 CI/CD 작업이 새로운 캐시를 사용합니다.

참고: 캐시를 수동으로 지울 때마다, 내부 캐시 이름이 업데이트됩니다. 해당 이름은 cache-<index> 형식을 사용하며, 인덱스가 하나씩 증가합니다. 이전 캐시는 삭제되지 않습니다. 이 파일들을 러너 저장소에서 수동으로 삭제할 수 있습니다.

문제 해결

캐시 불일치

캐시 불일치가 있는 경우, 아래 단계를 따라 문제를 해결하세요.

캐시 불일치의 원인 해결 방법
프로젝트에 공유 캐시 없이 독립형 러너(자동 스케일 모드가 아닌)를 여러 개 사용하는 경우 프로젝트에 하나의 러너만 사용하거나 분산 캐시를 사용하도록 여러 러너를 사용하세요.
분산 캐시를 사용하지 않은 상태에서 자동 스케일 모드 러너를 사용하는 경우 자동스케일 러너를 분산 캐시를 사용하도록 구성하세요.
러너가 설치된 디스크 공간이 부족하거나, 분산 캐시를 설정했을 경우, 캐시가 저장된 S3 버킷에 충분한 공간이 없는 경우 새로운 캐시가 저장될 수 있도록 공간을 비워주세요. 이 작업에는 자동 방법이 없습니다.
서로 다른 경로를 캐싱하는 작업에 동일한 key를 사용한 경우 다른 캐시 키를 사용하여 새로운 위치에 캐시 아카이브를 저장하고 잘못된 캐시를 덮어쓰지 않도록 합니다.
러너에서 분산 러너 캐싱을 사용하지 않은 경우 Shared = false를 설정하고 러너를 다시 프로비저닝하세요.

캐시 불일치 예제 1

프로젝트에 하나의 러너만 할당된 경우, 캐시는 기본적으로 러너의 머신에 저장됩니다.

두 작업이 동일한 캐시 키를 가지지만 다른 경로를 가질 때, 캐시가 덮어써질 수 있습니다. 예시: 

stages:
  - build
  - test

job A:
  stage: build
  script: make build
  cache:
    key: same-key
    paths:
      - public/

job B:
  stage: test
  script: make test
  cache:
    key: same-key
    paths:
      - vendor/
  1. job A가 실행됩니다.
  2. public/이 cache.zip으로 캐시됩니다.
  3. job B가 실행됩니다.
  4. 이전 캐시가 있다면, 이전 캐시를 푼 후, vendor/가 cache.zip으로 캐시되고 이전 것을 덮어씁니다.
  5. 다음에 job A가 실행될 때는 다른 곳에 저장된 job B의 캐시를 사용하게 되어 효과가 없어집니다.

이 문제를 해결하려면 각 작업에 다른 키를 사용하세요.

캐시 불일치 예제 2

이 예제에서는 프로젝트에 여러 개의 러너가 할당되어 있으며, 분산 캐시가 사용되지 않은 경우입니다.

다음으로 파이프라인을 실행하면, job A와 job B가 각자의 캐시를 재사용하도록 원합니다 (이 경우 다른 캐시입니다): 

stages:
  - build
  - test

job A:
  stage: build
  script: build
  cache:
    key: keyA
    paths:
      - vendor/

job B:
  stage: test
  script: test
  cache:
    key: keyB
    paths:
      - vendor/

키가 다르더라도, 다른 러너에서 다음 파이프라인에서 작업이 실행될 경우, 단계별로 각자 다른 러너에서 캐시 파일이 “정리될” 수 있습니다.

로컬 캐시가 없는 동시 실행 러너 문제

도커 실행기를 사용하여 여러 동시 실행 러너를 구성한 경우, 예상대로 동시에 실행되는 작업에 대해 로컬로 캐시된 파일이 존재하지 않을 수 있습니다. 캐시 볼륨의 이름은 각 러너 인스턴스마다 고유하게 생성되므로, 한 러너 인스턴스에서 캐시된 파일은 다른 러너 인스턴스에서 캐시에서 찾을 수 없습니다.

동시 실행 러너 간에 캐시를 공유하려면 다음 중 하나를 사용할 수 있습니다: - 러너가 고유한 볼륨 이름을 생성하지 않도록, 각 컨테이너의 /cache에 매핑된 호스트의 단일 마운트 지점을 구성하려면 러너들의 config.toml의 [runners.docker] 섹션을 사용하십시오. - 분산 캐시를 사용하세요.