# Demonstration: Watching Layer Caching Actually Work

## OBSERVE

```
$ docker build -t demo:1 .
Step 1/3 : FROM alpine:3.19
Step 2/3 : WORKDIR /app
Step 3/3 : COPY greeting.txt .
Successfully tagged demo:1
```

## HYPOTHESIS

Predict: if you run the EXACT same build again with no changes, will it take the same amount of
time?

## INSPECT

```
$ docker build -t demo:1 .
Step 1/3 : FROM alpine:3.19
Step 2/3 : WORKDIR /app
 ---> Using cache
Step 3/3 : COPY greeting.txt .
 ---> Using cache
Successfully tagged demo:1
```

`Using cache` — nearly instant, because nothing actually changed since the last build.

## CHANGE

Now change `greeting.txt`'s content and rebuild:

```
$ echo "updated" > greeting.txt
$ docker build -t demo:1 .
Step 2/3 : WORKDIR /app
 ---> Using cache
Step 3/3 : COPY greeting.txt .
 ---> (this step re-runs — the file changed)
```

Only the step AFTER the change re-runs — `WORKDIR` (unaffected) still used its cache.

## VERIFY

This is exactly why instruction ORDER matters: everything before the first changed instruction
stays cached; everything from that point onward must rebuild. Put your least-frequently-changing
instructions first.

## Instructor Notes

**Demo goal:** Make layer caching a directly OBSERVED behavior (via real build output), not an
abstract efficiency claim.

**Approximate timing:** 8 minutes live.

**Common mistake to watch for:** ordering a Dockerfile with frequently-changing application code
copied BEFORE installing rarely-changing dependencies — invalidates the expensive dependency-
install cache on every trivial code change.