Стратегия кэша и стоимости: иерархия restore-keys, стена вытеснения 10 ГБ и Docker layer cache

Ключ и лестница restore-keys

Когда добавляешь кэширование в CI, ты делаешь ставку: «это будет читаться чаще, чем стоит писать». Структура key и restore-keys — это то, что решает, окупится ставка или будет тихо сливать деньги каждый запуск.

Cache-action восстанавливает по первичному key и списку фолбэков restore-keys:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      npm-${{ runner.os }}-

key — это точное совпадение: хэш lockfile означает, что ключ меняется, только когда меняются зависимости, так что неизменный lockfile получает идеальное попадание, а изменённый — чистый промах (без устаревших зависимостей). На промахе restore-keys пробуются как префиксные совпадения, от самого свежего: npm-Linux- восстанавливает свежайший кэш от любого прошлого lockfile, так что бамп зависимости в одну строку всё равно тёпло стартует от вчерашнего node_modules и доустанавливает лишь дельту. Паттерн — специфичный key, широкий фолбэк — точный для корректности, префиксы для тепла. Кэш пишет новую запись только на промахе ключа; если точный ключ попал, новый кэш не сохраняется.

Стена 10 ГБ и LRU-вытеснение

Каждый репозиторий получает общий бюджет кэша 10 ГБ. Когда записи толкают его за 10 ГБ, GitHub вытесняет записи по least-recently-used — а кэши также вытесняются, если не тронуты 7 дней. Два следствия гонят реальную стоимость:

• Branch scope: кэш, созданный на ветке, читается этой веткой и дочерними ветками; кэши дефолтной ветки читаются всеми ветками. Так что кэширование на main засевает каждый PR, тогда как кэширование на каждой feature-ветке плодит записи с низким переиспользованием, лишь жрущие бюджет 10 ГБ.
• Вытеснение молчаливо и слепо к ценности: LRU не знает, что у твоего кэша зависимостей hit rate 95%, а у per-branch Docker-кэша 1%. Если низкоценные кэши пишутся свежее, они выталкивают высокоценный. Кэширование большего числа вещей может сделать CI медленнее, вытеснив кэш, который был важен.

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

Docker layer cache: мощно и легко злоупотребить

Для сборок контейнеров BuildKit может использовать кэш GitHub Actions как бэкенд layer-кэша (cache-from/cache-to: type=gha). Сделанное правильно, это пропускает пересборку неизменных слоёв — многоминутная сборка образа падает до секунд, когда изменился лишь слой приложения. Две ловушки: mode=max кэширует все промежуточные слои (отличный hit rate, но крупно — легко несколько ГБ, что съедает бюджет 10 ГБ и триггерит вытеснение), тогда как mode=min кэширует только финальные слои (меньше, ниже hit rate). И упорядочивание Dockerfile так, чтобы зависимости устанавливались до копирования кода, — вот что вообще заставляет кэш попадать; скопируй код первым, и каждая сборка инвалидирует слой зависимостей. Layer-кэширование — это рычаг, но жирный mode=max кэш, вытесняющий твой кэш зависимостей, или плохо упорядоченный Dockerfile, который никогда не попадает, стоит больше, чем холодная сборка.