Understanding Build Cache Print

  • 0

Why builds are fast or slow.

WHAT THE CACHE DOES

Reuses the result of an instruction when nothing it depends on has changed.

WHAT INVALIDATES IT

A changed instruction Changed files being copied Any earlier instruction being invalidated

WHY THAT LAST POINT DOMINATES

One early change rebuilds everything after it.

WHAT THAT ARGUES FOR

Ordering instructions from stable to volatile.

WHAT THE CLASSIC MISTAKE IS

Copying the entire source, then installing dependencies.

WHAT THAT CAUSES

Dependencies reinstalled on every source change.

WHAT TO DO INSTEAD

Copy only the dependency manifest, install, then copy the source.

WHAT TO BE CAREFUL WITH

Instructions fetching from the network.

WHY

The cache does not know the remote content changed.

WHAT THAT PRODUCES

Builds using stale packages.

WHAT TO DO ABOUT IT

Pin versions explicitly, rather than relying on cache invalidation.

WHAT A BUILD ARGUMENT PROVIDES

A value supplied at build time.

WHAT TO NEVER PASS AS ONE

A secret.

WHY

It is recorded in the image history and readable by anyone with the image.

WHAT TO USE INSTEAD

Build-time secret mounts, which are not persisted.

WHAT TO DO IN A PIPELINE

Persist the cache between runs, or builds start cold every time.


Was this answer helpful?
Back

Are you happy with your experience? Leave us a review on Trustpilot.


Trustpilot