Стратегия кеширования сборки

Действуй как Build Engineer. Спроектируй кеш-стратегию для {{build_system}}. Текущая сборка: {{current_duration}}.

Шаги

1. Измерь baseline.

   • Прогон cold build (cache очищен): сколько минут, какие самые тяжёлые шаги.
   • Прогон warm build: где реальный hit rate? Часто оказывается «5% от полезного».
   • Профиль: docker buildx --progress=plain, npm install --timing, bazel analyze-profile — посмотри, где живёт время.

2. Layer-strategy для Docker.

   • Порядок инструкций — от редко-меняющихся к часто-меняющимся. Шаблон:
     • FROM base
     • Install system deps (rarely changes)
     • COPY package.json package-lock.json
     • RUN npm ci (cache hit пока package-lock не менялся)
     • COPY source code
     • RUN build
   • --mount=type=cache (BuildKit) для npm/pip/cargo-кешей — кеш переживает между сборками, но не уходит в финальный образ.
   • docker buildx --cache-to/--cache-from в registry (GHCR, ECR) — кеш расшарен между runners.
   • Multi-stage: build stage кешируется отдельно от runtime stage.

3. Package manager caching.

   • npm/pnpm/yarn. Hash cache key по lockfile (hashFiles('**/package-lock.json')). pnpm: store-dir хранится в ~/.local/share/pnpm/store. Для GitHub Actions — actions/setup-node с cache: 'npm' делает это автоматически.
   • pip. Cache key по requirements.txt + python version. Уважай PIP_CACHE_DIR.
   • cargo. Кеш ~/.cargo/registry + target/ (но target/ огромен, hash по Cargo.lock + rust version + что собираем).
   • Gradle. Использует ~/.gradle/caches + remote build cache (Gradle Enterprise) для шаринга между разработчиками и CI.

4. Remote build cache (Bazel / Gradle / Turborepo).

   • Развёртывание: GCS/S3 bucket или managed (Buildbarn, BuildBuddy, Turborepo Remote Cache).
   • Принцип: action-level caching по content-hash inputs. Hit rate 70-90% при правильном setup.
   • Security: cache не должен возвращать чужой output (multi-tenant) — изоляция по namespace.
   • Read-only для PR (untrusted contributors), write — только из trusted runners.

5. Что меняет cache key (инвалидация).

   • Lockfile change → invalidate dependency cache.
   • Toolchain version change (node 20 → 22) → invalidate всё, что зависит от toolchain.
   • Environment variable меняет поведение build → она должна быть в cache key.
   • Часовой пояс / locale на runner — если влияет на output, инвалидируй.
   • Git ref для submodule.

6. Что НЕ кешировать.

   • Секреты (API tokens, certs) — никогда не должны быть build inputs. Используй secret-mount (BuildKit --mount=type=secret).
   • Dev dependencies в prod-артефакт — npm ci --omit=dev или multi-stage.
   • Стейджи с RUN apt-get update без pin версий — кеш будет stale, при rebuild подтянет другую версию пакета.
   • Personal-developer-state (auth tokens к npm registry) — токены в env, не в cache.

7. Мониторинг hit rate.

   • Логируй #cached, #bypassed шаги в CI summary.
   • Dashboard: hit rate per pipeline / per branch / per stage за 30 дней.
   • Алерт при hit rate < 50% на main — что-то сломалось.
   • Регулярный аудит: какие шаги «всегда холодные»? Часто фиксится перестановкой инструкций.

Anti-patterns

• ❌ COPY всего репо в начало Dockerfile — invalidates всё при любом изменении кода.
• ❌ npm install (lockfile может обновиться) вместо npm ci — недетерминированный кеш.
• ❌ Кеш растёт неограниченно (10+ GB) — TTL и size-based eviction обязательны.
• ❌ Один cache key на всё («build-cache-v1») — нулевая granularity, либо всё инвалидируется, либо stale.
• ❌ Cache между production и PR-сборкой одинаков — PR может отравить prod cache.
• ❌ Запекание .env в layer — секреты в registry, supply-chain disaster.

Формат вывода

## Baseline
| Stage | Cold | Warm | Hit rate |

## Strategy per layer
- Base image: ...
- Deps: ...
- Source: ...
- Build: ...

## Cache backend
- Tool: ...
- Storage: ...
- Eviction: ...
- ACL (read/write scopes): ...

## Cache key composition
`hash(lockfile) + toolchain + arch + ...`

## What NOT to cache (explicit list)

## Monitoring
- Metric: hit rate
- Dashboard link / query
- Alert: hit rate < X

## Expected improvement
| Stage | Before | After | Δ |

Принцип: кеш ускоряет «следующий» билд. Если он одновременно делает первый билд непредсказуемым (stale apt-get, неверсионированные base images) — это не кеш, это бомба замедленного действия.