Ответ
В GitLab CI/CD кеш — это механизм для сохранения файлов и директорий между разными запусками пайплайнов в рамках одного проекта. Его основная цель — ускорить выполнение jobs за счет повторного использования зависимостей (например, пакетов, скомпилированных объектов), избегая их повторной загрузки или сборки.
Базовый пример конфигурации в .gitlab-ci.yml:
cache:
key: ${CI_COMMIT_REF_SLUG} # Уникальный ключ (часто по ветке)
paths:
- node_modules/ # Кешируемые пути
- .gradle/caches/
policy: pull-push # Политика: скачать и обновить кеш
build_job:
script:
- npm ci # Быстрая установка из кешированных node_modulesКлючевые особенности и практика:
- Ключ (key): Определяет версию кеша. Использование
$CI_COMMIT_REF_SLUGсоздает отдельный кеш для каждой ветки. - Политики (policy):
pull-push(по умолчанию): job скачивает существующий кеш и обновляет его.pull: job только использует кеш, но не обновляет его (полезно для deploy-стадий).push: job только создает/обновляет кеш.
- Кеш vs Артефакты: Кеш не гарантирует сохранность и предназначен для ускорения сборки. Для передачи билдов между стадиями используйте
artifacts. - Очистка: Кеш может быть удален администратором или при нехватке места, поэтому критичные данные в нем хранить нельзя.
Ответ 18+ 🔞
А, слушай, про кеш в GitLab CI/CD. Ну это такая штука, чтобы не собирать всё с нуля каждый раз, как будто ты только что родился. Представь: ты каждый раз качаешь одни и те же пакеты, компилируешь одно и то же — это же пиздец как долго и тупо. Так вот, кеш — это типа твоя кладовка между запусками пайплайнов. Туда можно сложить node_modules, всякие кэши сборщиков, чтобы в следующий раз не начинать с пустого места.
Вот смотри, как это выглядит в конфиге, простейший пример:
cache:
key: ${CI_COMMIT_REF_SLUG} # Ключ, обычно по ветке. Для каждой ветки свой мешок с хламом.
paths:
- node_modules/ # Вот эту папку с зависимостями кешируем
- .gradle/caches/ # И эту тоже, чтоб Gradle не охуевал каждый раз
policy: pull-push # Политика: сначала забрал из кладовки, потом обратно запихнул
build_job:
script:
- npm ci # И вот тут уже npm не будет качать овердохуища пакетов, если они в кешеТеперь по полочкам, а то подозрение ёбать чувствую, что запутаешься.
Ключ (key) — это самое важное. Это как бирка на твоём мешке. Если пишешь $CI_COMMIT_REF_SLUG, то для ветки main будет один мешок, для feature/ebany — совсем другой. Не смешаются. Можно и по-другому, но это классика.
Политики (policy) — тут три варианта, как вести себя с этой кладовкой:
pull-push— дефолтный, жадный. Зашёл в job, взял из кеша что есть (pull), поработал, и обратно засунул обновлённое (push). Стандарт для сборки.pull— только забрал. Как стянул старыеnode_modules— и всё, ничего не кладёшь обратно. Идеально для стадии деплоя, где тебе ничего обновлять не надо.push— только положил. Редко, но бывает, когда job специально готовит кеш для других.
А теперь, блядь, важнейший момент! Не путай кеш с артефактами (artifacts). Это две большие разницы, ёпта!
- Кеш — это для скорости, для экономии времени. Он ненадёжный, его могут в любой момент выкинуть, если место кончится. Хранить в нём что-то ценное — идея хуйовая. Это просто временная подпорка.
- Артефакты — это для передачи результатов работы между стадиями. Собрал бинарник в одной job — положил в артефакты, а на следующей стадии его заберёшь и задеплоишь. Вот это — гарантированно сохранится на время пайплайна.
И последнее: очистка. Не рассчитывай на кеш как на каменную стену. Админ может его почистить, система сама может затереть, если переполнится. Поэтому если твой пайплайн без кеша не работает — это пизда рулю, чувак. Дизайн кривой. Кеш — это ускоритель, а не фундамент. Запомни это, и волнение ёбать отпадёт.