Skip the work you already did
Day 154 of 155
👉 Full deep-dive with code examples
The Freezer Batch Analogy
You cook the same stock every Sunday. It takes hours.
So you freeze a batch and write the recipe on the label: ingredients, quantities, cooking time.
Next Sunday, check the label:
- Label matches tonight's recipe → reheat it 🎉
- Recipe changed → cook fresh, freeze it under a new label
The label is the cache key. The frozen batch is the cached output.
Why Builds Are Slow Without It
A fresh CI runner starts with an empty disk:
checkout → quick
install → download every dependency again
build → recompile every file again
Your dependencies did not change since yesterday. Most of your source files did not either.
The runner has no memory, so it repeats all of it 😫
The Cache Key
Hash the inputs, then look up the result.
key = hash(lockfile + toolchain version + OS + flags)
hit → restore the output, skip the step
miss → do the work, save it under the new key
The rule: the key should cover every input that can change the output.
A Real Workflow
A typical Node CI workflow sets up every job the same way:
- uses: actions/setup-node@v7
with:
node-version: '22'
cache: 'npm'
That restores npm's download cache, keyed on a hash of package-lock.json. The job still runs npm ci, but packages come off local disk instead of the network.
Change the lockfile and the key changes, so the next run installs fresh.
The Catch
A key that leaves out a real input hands you a stale result that looks correct. A slow pipeline is annoying; a wrong one costs you an afternoon.
In One Sentence
Build caching hashes the inputs of a step so a later run with matching inputs restores the stored output instead of redoing the work.
🔗 Enjoying these? Follow for daily ELI5 explanations!
Making complex tech concepts simple, one day at a time.
Top comments (0)