13 Фев
Современный CI/CD — это не просто автоматизация деплоя, это в первую очередь борьба за скорость. Каждый раз, когда ваш workflow запускается в GitHub Actions, он стартует на «чистой» виртуальной машине. Это значит, что такие тяжелые этапы, как npm install, выполняются с нуля, скачивая сотни мегабайт из сети. В этой статье рассмотрим Кэширование в GitHub Actions.
В этой статье мы разберем, как использовать механизм кэширования (GitHub Actions Cache), чтобы сократить время сборки в разы и перестать тратить драгоценные минуты CI-сервера на рутинную загрузку одних и тех же пакетов.
Зачем нужен кэш в CI/CD?
Представьте типичный сценарий: вы поправили одну опечатку в коде или изменили цвет кнопки. Вы делаете push, запускается workflow, и… вы ждете 3–5 минут, пока установятся зависимости node_modules. Если проект большой, это ожидание превращается в пытку и тормозит весь процесс разработки.
Кэширование позволяет сохранять папки с зависимостями между запусками. Если файл со списком зависимостей (например, package-lock.json) не менялся, GitHub Actions просто возьмет готовую папку из хранилища вместо того, чтобы запускать полноценную установку.
Основные инструменты
Для работы нам понадобятся два официальных экшена:
- actions/cache — универсальный инструмент для кэширования любых файлов и папок.
- actions/setup-node — имеет встроенные механизмы оптимизации, но для гибкого управления сложными зависимостями лучше комбинировать его с основным экшеном кэша.
Пошаговая настройка кэширования для Node.js
Рассмотрим пример конфигурации .yml файла для вашего workflow. Основная задача — закэшировать папку node_modules и привязать её к состоянию вашего проекта.
1. Создание ключа кэширования
Ключ — это уникальный идентификатор кэша. Самый эффективный способ — генерировать его на основе хэш-суммы файла зависимостей. Если вы добавили новый пакет, хэш изменится, ключ станет невалидным, и GitHub Actions создаст новый кэш.
- name: Cache node modules
id: cache-npm
uses: actions/cache@v4
with:
path: node_modules
key: ${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-
${{ runner.os }}-2. Динамические зависимости
Использование hashFiles('**/package-lock.json') гарантирует, что кэш будет обновляться ровно тогда, когда это нужно.
- path: Указывает, какую именно папку мы сохраняем.
- key: Основной ключ для поиска кэша.
- restore-keys: Запасные ключи. Если точного совпадения по хэшу нет (например, вы добавили одну библиотеку), GitHub попробует восстановить максимально близкий по названию кэш, что всё равно ускорит последующий
npm install.
Как это работает на практике
После внедрения кэша логика выполнения workflow меняется:
- Первый запуск: Кэш не найден. Выполняется полная установка зависимостей. В конце работы GitHub сохраняет папку
node_modulesв облако. - Повторный запуск (без изменений зависимостей): Экшен находит кэш по ключу и мгновенно распаковывает его. Шаг
npm installотработает за доли секунды, так как все файлы уже на месте. - Обновление зависимостей: Если вы обновили
package-lock.json, ключ не совпадет. Система создаст новый слой кэша, обеспечивая актуальность сборки.
Мониторинг и управление кэшем
В интерфейсе GitHub на вкладке Actions есть специальный раздел Caches. Там вы можете:
- Видеть список всех сохраненных архивов.
- Отслеживать их размер.
- Вручную удалять устаревшие кэши, если они занимают слишком много места (хотя GitHub автоматически удаляет кэш, к которому не обращались более 7 дней).
Заключение
Настройка кэширования в GitHub Actions — это «low hanging fruit» (низко висящий фрукт) в мире DevOps. Это требует минимум усилий, но дает колоссальный прирост производительности. Если вы цените свое время и хотите сделать процесс деплоя максимально комфортным, кэширование зависимостей должно быть в каждом вашем проекте.
