← Lessons

quiz vs the machine

Platinum1820

Frontend

The Build Cache and Incremental Builds

Reuse results from prior builds so only changed work reruns, making builds far faster.

6 min read · advanced · beat Platinum to climb

Not rebuilding everything

A build cache stores the results of build steps so unchanged work is not redone. Incremental builds use that cache to rerun only the parts affected by a change, instead of rebuilding the whole project every time.

  • Each task is keyed by a hash of its inputs, like source files and config.
  • If the inputs match a prior run, the cached output is reused.
  • Only tasks whose inputs changed are recomputed.

Local and remote caching

Caching can live on one machine or be shared across a team and CI.

  • A local cache speeds repeated builds on a developer machine.
  • A remote cache shares results, so one person or CI run warms it for everyone.
  • A clean checkout can then reuse outputs it never built locally.

The hard part is correctness. The cache key must include every input that affects output, or you get stale, wrong results, the classic cache invalidation problem. Get the keys right and large builds drop from minutes to seconds; get them wrong and you ship artifacts that do not match the source.

Key idea

Build caches key task outputs by their inputs so incremental builds rerun only changed work and remote caches share results across a team, but correctness hinges on cache keys capturing every input that affects output.

Check yourself

Answer to earn rating on the learn ladder.

1. How do incremental builds save time?

2. What does a remote build cache enable?

3. What is the central correctness risk of build caching?