CI Cache Optimizer

CI Cache Optimizer

Expert in reducing CI/CD build times through dependency caching, Docker layer caching, and build pipeline optimization.

Activation Triggers

Activate on: "CI cache", "build speed", "dependency caching", "Docker layer cache", "turbo remote cache", "GitHub Actions cache", "pnpm store cache", "slow builds", "CI optimization"

NOT for: Pipeline creation → github-actions-pipeline-builder | Deployment strategy → blue-green-deployment-orchestrator | Docker builds → docker-multi-stage-optimizer

Quick Start

1. Profile the build — measure time per step to find the bottleneck (usually dependency install or Docker builds)
2. Cache dependencies — restore package manager cache (pnpm store, pip cache, Go module cache)
3. Cache Docker layers — use BuildKit cache or GitHub Actions Docker cache
4. Cache build outputs — Turborepo remote cache, Next.js build cache, compiled artifacts
5. Parallelize — split test suites, build independent packages concurrently

Core Capabilities

Architecture Patterns

GitHub Actions Dependency Cache (pnpm)

# .github/workflows/ci.yml
- uses: pnpm/action-setup@v4
  with:
    version: 9

- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'           # Built-in pnpm cache support

# Turbo remote cache for monorepo build outputs
- name: Build
  run: pnpm turbo build --cache-dir=.turbo
  env:
    TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
    TURBO_TEAM: ${{ vars.TURBO_TEAM }}

Docker Layer Cache Strategies

# Strategy 1: GitHub Actions cache backend (fastest for GHA)
- uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: myapp:latest
    cache-from: type=gha
    cache-to: type=gha,mode=max

# Strategy 2: Registry cache (works across CI providers)
- uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: registry.io/myapp:latest
    cache-from: type=registry,ref=registry.io/myapp:cache
    cache-to: type=registry,ref=registry.io/myapp:cache,mode=max

Cache Hierarchy (What to Cache, in Priority Order)

Priority 1 — Dependency install (biggest time save):
  ├─ pnpm store: ~/.local/share/pnpm/store
  ├─ pip cache: ~/.cache/pip
  ├─ Go modules: ~/go/pkg/mod
  └─ Cargo registry: ~/.cargo/registry

Priority 2 — Build outputs (incremental builds):
  ├─ Turbo remote cache: .turbo/
  ├─ Next.js: .next/cache
  ├─ TypeScript: tsconfig.tsbuildinfo
  └─ Webpack: node_modules/.cache

Priority 3 — Docker layers (image builds):
  ├─ BuildKit cache mounts
  ├─ Docker layer cache (gha or registry)
  └─ Multi-stage build ordering

Priority 4 — Test artifacts (expensive to regenerate):
  ├─ Playwright browsers: ~/.cache/ms-playwright
  ├─ Cypress: ~/.cache/Cypress
  └─ Snapshot baselines

Anti-Patterns

1. Caching node_modules directly — fragile and large. Cache the pnpm/npm store instead; the install step uses the cached store and is near-instant.
2. No cache key versioning — stale caches cause mysterious failures. Include lockfile hash in the cache key: key: deps-${{ hashFiles('pnpm-lock.yaml') }}.
3. Caching everything — caching small files that are fast to regenerate wastes time on cache download. Only cache what saves more time than the restore cost.
4. Missing restore-keys fallback — if the exact cache key misses, the build starts cold. Use restore-keys with prefix matching for partial cache hits.
5. Not profiling first — adding caching without knowing the bottleneck. Measure step durations first; the slowest step gets caching priority.

Quality Checklist

[ ] CI build time profiled and bottleneck identified
[ ] Dependency cache uses lockfile hash as cache key
[ ] Fallback restore-keys configured for partial hits
[ ] Docker builds use BuildKit with cache-from/cache-to
[ ] Turbo/Nx remote cache enabled for monorepo builds
[ ] Test browser binaries cached (Playwright, Cypress)
[ ] Cache size monitored (GitHub Actions: 10GB limit)
[ ] Stale caches cleaned via retention or key rotation
[ ] Parallel jobs configured for independent packages
[ ] Build time target set (e.g., < 5 minutes for PR checks)
[ ] Cache hit rate tracked (> 80% target)
[ ] Before/after metrics documented for optimization efforts