Кэширование зависимостей для ускорения сборок

Большая часть времени CI уходит на загрузку и установку одних и тех же зависимостей при каждом запуске. Кэширование сохраняет их между запусками, чтобы последующие сборки повторно использовали выполненную работу, часто значительно сокращая время конвейера.

GitHub предоставляет actions/cache. Вы указываете путь для кэширования и ключ, который идентифицирует запись кэша. При попадании в кэш путь восстанавливается, а при промахе сохраняется после завершения задания.

Ключ должен меняться только тогда, когда должно измениться кэшируемое содержимое. Идеально вычислять хэш файла блокировок: новый файл блокировок означает новые зависимости, поэтому создаётся новая запись кэша.

restore-keys задаёт резервные префиксы. Если точный ключ не найден, действие восстанавливает самый свежий кэш, ключ которого начинается с одного из префиксов, обеспечивая частично прогретый запуск.

При точном совпадении ключа происходит попадание в кэш, и путь восстанавливается. При промахе задание выполняется обычным образом, а в конце кэш сохраняется с основным ключом и будет готов к следующему запуску.

Действия настройки языковой среды уже поддерживают кэширование. Для Node действие setup-node с параметром cache: npm самостоятельно управляет кэшем зависимостей, поэтому отдельный шаг кэширования не нужен.

Кэшируйте каталоги загрузок менеджера пакетов, а не установленный каталог node_modules, если это возможно: кэши загрузок переносимы, а шаг установки всё равно проверяет целостность.

• Node: ~/.npm
• Python: кэш pip
• Java: ~/.m2 или кэши Gradle

Область действия кэшей ограничена веткой (с резервным переходом к ветке по умолчанию), а для каждого репозитория установлен предельный размер. Неиспользуемые кэши со временем удаляются, поэтому проектируйте ключи так, чтобы они корректно обновлялись.

Если ключ никогда не меняется, Вы можете использовать устаревшие зависимости. Всегда связывайте ключ с хэшем файла блокировок, чтобы обновления автоматически делали кэш недействительным.

При матричных сборках для разных ОС или версий включайте runner.os и версию в ключ, чтобы каждый вариант получал собственный корректный кэш, а не конфликтовал с другими.

Сравните длительность заданий до и после кэширования и следите за индикатором попадания в кэш в журналах. Стабильно низкая доля попаданий указывает на ключ, который меняется слишком часто.

Проверьте, насколько хорошо Вы поняли кэширование зависимостей.

Вы ускорили CI с помощью кэширования зависимостей: действия actions/cache с ключом, основанным на хэше файла блокировок, и резервным вариантом restore-keys, встроенное кэширование в действиях настройки, выбор объектов для кэширования, включение ОС и версии в матричные ключи, а также предотвращение устаревания кэша за счёт привязки ключа к файлу блокировок.