CI/CD Image Building

Building on Ephemeral Runners

CI machines are throwaway, so the local builder cache is gone every run. Use BuildKit through buildx and store layers in a shared backend:

docker buildx build   --cache-from type=gha   --cache-to   type=gha,mode=max   --tag app:${GITHUB_SHA::8}   --file Dockerfile .

mode=max exports every intermediate layer, not just the final stage — without it, npm ci layers from earlier stages never survive between runs. Build the image even when you will not push it: a build step on pull requests catches broken Dockerfiles before merge.

Tagging and Release Builds

Derive tags from git so every image maps to a commit:

SHA=$(git rev-parse --short HEAD)
docker buildx build   --tag registry.example.com/app:$SHA   --tag registry.example.com/app:latest   --push .

latest is convenience for humans; automation should pin the SHA tag or digest. For multi-arch releases, add --platform linux/amd64,linux/arm64 with QEMU registered — the result is a manifest list, and one tag serves both architectures. Attach provenance with --provenance=true so consumers can verify what was built and from which source.

Pitfalls and Interview Angles

Cache misses after the first COPY. Adding COPY . . early invalidates every later layer on each commit — order the Dockerfile so dependency install runs before source copy.

Secrets in build args. --build-arg TOKEN=... is recorded in image history and visible to anyone who pulls it; use BuildKit --mount=type=secret instead.

Built is not tested. Run unit tests in the pipeline before the build, then smoke-test the built image (start the container, hit /healthz) — the image is the artifact that ships.

Interview: explain the buildx cache backends you would choose (gha for GitHub, registry for portability), where mode=max matters, and how you would prove a rebuild reused cache.