Что такое кеш в GitLab?

Что такое кеш в GitLab?

Кеш (cache) в GitLab — это механизм для оптимизации времени выполнения CI/CD задач, позволяющий сохранять и повторно использовать данные между запусками pipeline. Основная цель — избежать повторения операций, таких как установка зависимостей или компиляция артефактов, что значительно сокращает продолжительность jobs и экономит ресурсы.

Типы кеша в GitLab CI/CD

В GitLab можно использовать несколько видов кеша:

1. Cache для зависимостей и артефактов — наиболее распространённый тип. Определяется в .gitlab-ci.yml с помощью ключа cache. Он сохраняет указанные файлы и директории (например, node_modules, vendor для PHP, .gradle для Java) на runner и загружает их в последующих запусках.

   cache:
     key: "$CI_COMMIT_REF_SLUG"
     paths:
       - node_modules/
       - .cache/
   

    Здесь `key` определяет уникальный идентификатор кеша. Использование переменных окружения, таких как `$CI_COMMIT_REF_SLUG` (имя ветки), позволяет создавать отдельные кеши для разных веток.

1. Кеш для Docker слоёв (layer caching) — применяется в jobs, использующих Docker. Например, при сборке Docker образов можно кешировать промежуточные слои, чтобы избежать повторной загрузки базового image или повторного выполнения apt-get install.

   build_image:
     script:
       - docker build --cache-from $CI_REGISTRY_IMAGE:latest -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
   

2. Неявный кеш GitLab Runner — Runner сам может кешировать Docker images или другие данные для ускорения подготовки среды выполнения (executor).

Как работает кеш?

При выполнении job GitLab Runner:

• Загружает (pull) кеш из хранилища, если он существует для текущего key.
• Выполняет команды из script.
• Сохраняет (push) кеш указанных paths после успешного завершения job (или при определённых условиях, например, даже при неудачном job, если задано cache: policy: pull-push).

Кеш хранится на самом runner (локально) или в общем хранилище (например, Amazon S3, Google Cloud Storage), если настроена distributed cache. Это важно для больших проектов с множеством runners.

Стратегии управления кешем (cache policy)

В .gitlab-ci.yml можно задавать политики:

• pull-push (default) — загрузить существующий кеш перед job и сохранить новый после.
• pull — только загрузить, но не сохранять изменения (например, для jobs только чтения).
• push — только сохранить новый кеш (например, для job подготовки зависимостей).

prepare_deps:
  cache:
    key: deps
    paths:
      - vendor/
    policy: push
  script:
    - composer install

test:
  cache:
    key: deps
    paths:
      - vendor/
    policy: pull
  script:
    - phpunit

Ключевые особенности и ограничения

• Кеш не является артефактом — он предназначен для временного ускорения jobs, а не для передачи данных между stages или окончательного сохранения результатов. Для передачи файлов между stages используйте artifacts.
• Кеш может стать "грязным" — если зависимости меняются между коммитами, но key остаётся одинаковым (например, кеш для всей ветки), это может привести к использованию некорректных данных. Часто используют key: "$CI_COMMIT_REF_SLUG-$CI_PROJECT_ID" или даже key: "$CI_COMMIT_SHA" для более точного соответствия.
• Объём кеша ограничен — можно задать глобально в настройках Runner или проекта. Старый кеш удаляется по политикам LRU (Least Recently Used).

Практический пример: кеширование в Node.js проекте

image: node:16

cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - node_modules/
    - .npm/

stages:
  - install
  - test
  - build

install_dependencies:
  stage: install
  script:
    - npm ci --cache .npm --prefer-offline

run_tests:
  stage: test
  script:
    - npm test

build_app:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

В этом примере:

• Кеш сохраняет node_modules и директорию .npm (где npm хранит свой внутренний кеш).
• В job install_dependencies используется npm ci (чистая установка) с флагом --prefer-offline, чтобы максимально использовать локальный кеш .npm.
• Jobs run_tests и build_app используют загруженный кеш node_modules, не тратя время на повторную установку.
• Результат сборки (dist/) передаётся как artifact, а не как кеш.

Итог: Кеш в GitLab — мощный инструмент для оптимизации CI/CD, требующий внимательной настройки ключей и политик. Правильное использование сокращает время pipeline на 50-80% для проектов с большими зависимостями, повышая эффективность разработки. Однако важно помнить о его временном характере и различии с артефактами.