cache-key стратегии
Тема дорожной карты · GitHub Actions
Стратегии cache-ключей в GitHub Actions определяют, получит ли запуск workflow сохранённый кеш или создаст новый, непосредственно влияя на скорость и корректность CI/CD-пайплайна. Основной cache-ключ — это строка, формируемая с помощью выражений вида ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}, где hashFiles вычисляет детерминированный отпечаток, чтобы action actions/cache@v3 автоматически инвалидировал кеш при изменении зависимостей. При промахе по основному ключу GitHub Actions перебирает упорядоченный список префиксов restore-keys:, допуская частичные попадания в кеш, которые всё равно существенно экономят время загрузки на runner непрерывной интеграции. Эффективные стратегии cache-ключей включают в ключ ОС, версию языковой среды выполнения и хеш lock-файла, чтобы исключить перекрёстное загрязнение между matrix-сборками или разными ветками workflow. Дисциплинированное проектирование cache-ключей необходимо для быстрой и надёжной автоматизации пайплайна: слишком широкие ключи рискуют подавать устаревшие артефакты, а слишком узкие снижают процент попаданий и нивелируют пользу от кеширования.
Как это работает
cache-key стратегии: артефакты (actions/upload-artifact, download-artifact) персистят файлы между jobs внутри workflow (и после завершения — для скачивания через UI). Кеш (actions/cache) ускоряет повторную работу, сохраняя + восстанавливая директории по hash-ключу (hashFiles('package-lock.json')). Cache-hit драматичен для больших деревьев зависимостей. Scope кеша: ветка + ключ; кеш main-ветки расшарен на PR из форков read-only.
Когда применять
Кеш — для ~/.npm, ~/.pnpm-store, ~/.cargo, ~/.gradle, ~/.m2, Docker-слоёв через buildx cache, OS-пакетов. Артефакты — для передачи build-output между jobs (build → test → deploy с общим скомпилированным output). restore-keys: — fallback на cache-miss. Retention-политика — артефакты по дефолту 90 дней.
Типичные ошибки
Ловушки cache-key стратегии: cache-key никогда не меняется (кешируете раз, всегда восстанавливаете тот же stale-кеш); кеш превышает 10GB/repo-лимит GitHub (старейшие entry вытесняются — иногда не те); дефолт retention артефактов 90 дней (стоимость storage растёт — снижайте для ephemeral-сборок).