Ответ
Кеш в GitLab — это механизм хранения промежуточных данных (например, зависимостей, артефактов сборки) для ускорения последующих запусков пайплайнов. Он позволяет избежать повторной загрузки или генерации одних и тех же файлов, экономя время и ресурсы.
Пример использования в .gitlab-ci.yml:
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
- .cache/Нюансы:
- Кеш не гарантирует сохранность данных (может быть очищен).
- Для критичных данных лучше использовать
artifacts. - Можно настраивать политики инвалидации через
key(например, по ветке).
Ответ 18+ 🔞
Ну, слушай, смотри, есть такая штука в GitLab — кеш. Это типа такая хитрая жопа, которая запоминает всякий хлам, который у тебя нагенерировалось в процессе работы: там библиотеки, какие-то временные файлы, прочее говно. Суть в чём? Чтобы в следующий раз, когда ты запускаешь пайплайн, не начинать с нуля, а взять уже готовенькое из закромов. Экономия времени — овердохуища, особенно если зависимости тяжёлые.
Вот, смотри, как это в конфиге выглядит, простейший пример:
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
- .cache/Видишь? Говорим: "Запоминай, блядь, всё, что в node_modules и .cache". А ключ (key) — это чтобы понимать, откуда брать сохранённую копию. Тут по имени ветки, например.
Но вот, бля, нюансы, которые в рот меня чих-пых!
Во-первых, кеш — это не священный артефакт, его могут в любой момент почистить, как старый хлам. На него надейся, но сам не проебибна. Если файлы критически важные и их обязательно нужно передать между джобами — это artifacts, а не кеш.
Во-вторых, с ключами можно выёбываться. Можно завязать их на версию lock-файла, например, чтобы кеш инвалидировался только когда зависимости реально поменялись, а не просто потому что коммит новый. А то бывает настроишь криво — и он каждый раз всё заново качает, терпения ебать ноль.
Короче, штука полезная, но подходить к ней надо с мозгом, а не просто скопипастить и забыть. Иначе вместо ускорения получишь волнение ебать, где же твой кеш-то делся.