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

GitLab Cache: оптимизация CI/CD пайплайнов

Определение

Cache в GitLab - это механизм для сохранения файлов между запусками pipeline, чтобы не пересчитывать их каждый раз. Это ускоряет builds и экономит время.

Без кеша:
Build 1: скачать зависимости (5 минут) → компилировать (2 минуты)
Build 2: скачать зависимости (5 минут) → компилировать (2 минуты)
Build 3: скачать зависимости (5 минут) → компилировать (2 минуты)
Всего: 21 минута

С кешем:
Build 1: скачать зависимости (5 минут) → компилировать (2 минут) → сохранить кеш
Build 2: восстановить кеш (1 сек) → компилировать (2 минуты)
Build 3: восстановить кеш (1 сек) → компилировать (2 минуты)
Всего: 11 минут

Экономия: 45% времени!

Типы хранилища

GitLab поддерживает разные backend'ы для кеша:

1. Shared runners (по умолчанию)

   • Используется локальный диск runner'а
   • Быстро, но потеряется если runner перезагружается

2. S3-совместимое хранилище

   • MinIO, AWS S3, DigitalOcean Spaces
   • Persists, но медленнее

3. Google Cloud Storage

   • Для облачных deployments

Синтаксис

image: python:3.9

# Определи что кешировать
cache:
  paths:
    - .cache/pip              # Python dependencies
    - node_modules/           # Node dependencies
    - build/                  # Compiled artifacts
  # Ключ кеша (важно!)
  key: "${CI_COMMIT_REF_SLUG}"
  # Когда использовать кеш
  policy: pull-push           # read-write

stages:
  - build
  - test

build:
  stage: build
  script:
    - pip install -r requirements.txt
    - python setup.py build

test:
  stage: test
  script:
    - pytest tests/

Практический пример

image: python:3.9

# Cache для Python зависимостей
cache:
  paths:
    - .cache/pip
    - venv/
  key:
    files:
      - requirements.txt      # Ключ меняется если requirements.txt изменился
    prefix: ${CI_COMMIT_REF_SLUG}

stages:
  - install
  - test
  - deploy

install_dependencies:
  stage: install
  script:
    # Установи в кешированную папку
    - pip install --cache-dir .cache/pip -r requirements.txt
    # Или с venv
    - python -m venv venv
    - source venv/bin/activate
    - pip install -r requirements.txt
  cache:
    paths:
      - .cache/pip
      - venv/
    key: "${CI_COMMIT_REF_SLUG}-python"
    policy: pull-push

test:
  stage: test
  script:
    - source venv/bin/activate  # восстанови venv из кеша
    - pytest tests/
  cache:
    paths:
      - venv/
    key: "${CI_COMMIT_REF_SLUG}-python"
    policy: pull                # только читай из кеша

deploy:
  stage: deploy
  script:
    - source venv/bin/activate
    - python app.py
  cache:
    paths:
      - venv/
    key: "${CI_COMMIT_REF_SLUG}-python"
    policy: pull                # только читай

Ключи кеша

# Простой ключ (одинаков для всех веток)
cache:
  key: "my-cache"

# Ключ по ветке
cache:
  key: "${CI_COMMIT_REF_SLUG}"
  # feature/new-api → кеш отдельно от main
  # staging → кеш отдельно

# Ключ по файлу (меняется если файл изменился)
cache:
  key:
    files:
      - requirements.txt
      - setup.py

# Ключ по файлу + ветка
cache:
  key:
    files:
      - requirements.txt
    prefix: "${CI_COMMIT_REF_SLUG}"

Policy: что делать с кешем

# pull-push (по умолчанию)
# Скачай кеш, используй его, обновляй в конце
cache:
  policy: pull-push
  # 1. Восстанови из кеша
  # 2. Запусти job
  # 3. Сохрани обновлённый кеш

# pull
# Только скачивай, не сохраняй
cache:
  policy: pull
  # Используется для jobs которые не меняют кеш
  # (например, тесты которые читают из кеша)

# push
# Только сохраняй, не скачивай
cache:
  policy: push
  # Редко используется

Пример с ML проектом

image: python:3.9

stages:
  - prepare
  - train
  - evaluate
  - deploy

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

prepare_data:
  stage: prepare
  script:
    # Скачай датасет
    - pip install --cache-dir $PIP_CACHE_DIR -r requirements.txt
    - python scripts/download_data.py
    # Обработай данные
    - python scripts/prepare_data.py
  artifacts:
    paths:
      - data/processed/
    expire_in: 1 week
  cache:
    paths:
      - .cache/pip
    key: "${CI_COMMIT_REF_SLUG}-ml"

train_model:
  stage: train
  script:
    - pip install --cache-dir $PIP_CACHE_DIR -r requirements.txt
    # Восстанови обработанные данные
    - python scripts/train.py
  dependencies:
    - prepare_data  # нужны выходы от prepare_data
  artifacts:
    paths:
      - models/
    expire_in: 30 days
  cache:
    paths:
      - .cache/pip
    key: "${CI_COMMIT_REF_SLUG}-ml"

evaluate:
  stage: evaluate
  script:
    - pip install --cache-dir $PIP_CACHE_DIR -r requirements.txt
    - python scripts/evaluate.py
  artifacts:
    reports:
      metrics: metrics.json
  cache:
    paths:
      - .cache/pip
    key: "${CI_COMMIT_REF_SLUG}-ml"
    policy: pull  # только читаем

Проблемы и решения

1. Кеш не используется

# Проблема: ключ меняется каждый раз
cache:
  key: "${CI_BUILD_ID}"  # НЕПРАВИЛЬНО!
  # ID уникален для каждого запуска

# Решение: используй стабильный ключ
cache:
  key: "${CI_COMMIT_REF_SLUG}"  # ПРАВИЛЬНО
  # Одинаков для всех запусков на одной ветке

2. Кеш потребляет много места

# Ограничь размер
cache:
  paths:
    - .cache/pip
  untracked: false  # не кешируй untracked файлы

3. Кеш заражён (содержит старые файлы)

# Очистка вручную
# В меню проекта → CI/CD → Pipelines → Clear Runner Caches
# Или через API
curl --request DELETE \
  --header "PRIVATE-TOKEN: <token>" \
  "https://gitlab.com/api/v4/projects/1/runner_caches"

Лучшие практики

# 1. Кешируй только нужное
cache:
  paths:
    - node_modules/       # OK: большие зависимости
    - build/artifacts/    # OK: скомпилированные файлы
    - src/                # BAD: исходный код не нужно кешировать

# 2. Используй правильный ключ
cache:
  key:
    files:
      - requirements.txt   # Перестраивай если изменились зависимости
      - Dockerfile        # Перестраивай если изменился Docker

# 3. Выдели разные кеши для разных jobs
job1:
  cache:
    key: "job1-cache"
    paths: [...]

job2:
  cache:
    key: "job2-cache"
    paths: [...]  # другой кеш

# 4. Используй policy правильно
job_that_creates_cache:
  cache:
    policy: pull-push  # создаёт и обновляет

job_that_uses_cache:
  cache:
    policy: pull       # только использует

Когда использовать

Используй кеш для:

1. Зависимости (pip, npm, gems)
2. Скомпилированные артефакты (bytecode, .so файлы)
3. Промежуточные результаты (processed data, feature vectors)
4. Среды окружения (venv, node_modules)

НЕ используй кеш для:

1. Исходный код (в git уже есть)
2. Большие данные (use artifacts + S3 вместо)
3. Секреты (использую variables вместо)
4. Часто меняющиеся файлы (кеш может быть несвежим)

Заключение

GitLab Cache - это простой способ ускорить CI/CD пайплайны путём сохранения файлов между запусками. Правильное использование кеша может снизить время сборки в 2-5 раз. Ключ к успеху - правильно выбрать ключ кеша и что кешировать.