Cloud Build's documented cache paths miss the layer that costs 30 to 60 seconds a push

The tell is in what a published image actually contains. `--cache-from <previous image>` offers the layers of that image as cache candidates ^[5]. A final image carries the layers of its final stage. Whatever the builder stage did was thrown away when the build moved on, so nothing pointing at the published tag can bring it back, which is why the write-up's author calls the miss silent ^[6]. The flag is accepted and the build succeeds; the expensive layer gets rebuilt anyway.

The author identifies BuildKit's registry cache with `mode=max` as the mode that actually persists that dependency layer, and says neither documented path mentions it ^[8]. The store is already in the project: Artifact Registry, shared by every build ^[4].

That only pays if the Dockerfile is ordered for it. A layer survives when both its instruction and its input context are unchanged, and invalidating one layer invalidates every layer beneath it ^[11]. So the lockfile copy and the install go above the source copy ^[12]; with `pyproject.toml` and `uv.lock` untouched, uv re-downloads nothing ^[14].

Now the number. The 30 to 60 seconds is attributed to a Python app with a few dozen packages ^[9], while the demo in the article is FastAPI plus uvicorn with a 21-package transitive tree ^[13], and the published text carries no before-and-after timing ^[19]. For that figure to transfer, dependency resolution has to dominate your build, the layer order has to put the lockfile above the source, and pulling the cache manifest and blobs out of Artifact Registry has to cost less than re-resolving them. `mode=max` stores more layers than a final-image cache, so there is more to pull and more to keep, and the write-up prices neither ^[19].

Take the top of the range and a pipeline firing ten times a working day: 60 s x 10 x 250 = 150,000 s, about 42 hours of worker time a year, with the bottom of the range landing near 21 hours ^[18]. Per pipeline. That is the size of the prize and also its ceiling.

The documentation is the part I would escalate. Google archived Kaniko on June 3, 2025, with a notice that the project is no longer developed or maintained ^[7], and the author reports the official guidance still offers it as one of two cache options ^[5]. That leaves `--cache-from` as the live documented route, which is the one that skips the builder stage ^[6]. Guidance pointing at an archived project is still guidance; the build just does not get faster. The author also notes that almost nobody in his circle, including the Google Developer Expert community, persists the Docker cache on Cloud Build at all ^[16], which is what you would expect when the default makes caching look broken ^[2].

In my context the trade is easy: a Python image where dependency install dominates, a registry in the same project, a lockfile that moves weekly. If the slow part of your image is a compile step that changes with every commit, the registry cache buys you the pull and little else.