Registries and artifact identity

A useful name is not an immutable identity

An image is a build artifact: an output that can be stored, tested, and selected for deployment. A registry stores and distributes images. A reference such as registry.example/team/service:qa contains a registry, repository, and tag. The tag is a movable name, so two requests for :qa at different times can resolve to different content.

A digest identifies content. A published multi-platform image may refer to an index that selects a platform-specific manifest; the index and selected manifest have different digests. A local image ID identifies another part of the image representation. Record which one you mean instead of calling every SHA value “the image digest.”

Compare two names for one local image

Use the built learnwithsk-status:dev fixture. These commands do not publish anything:

docker image inspect learnwithsk-status:dev --format '{{.Id}}'
docker image inspect learnwithsk-status:dev --format '{{json .RepoDigests}}'
docker image tag learnwithsk-status:dev learnwithsk-status:review
docker image inspect learnwithsk-status:review --format '{{.Id}}'

Expected: both tags point to the same local image ID. A locally built image may have an empty repository-digest list because it has not been pulled or pushed under a registry reference. An empty list is not evidence of a broken build.

In docker-status, change the JSON body to {"status":"changed"} and rebuild only learnwithsk-status:dev. Inspect both tags again. The new dev image should have a different ID, while review still refers to the old one. Tags are independent references; rebuilding one does not update every tag that once shared its target. Restore the fixture to ok and rebuild dev before the lab.

Remove the extra local reference with docker image rm learnwithsk-status:review. Keep dev for the remaining exercises. A container created earlier still refers to the image selected when it was created; updating a tag does not mutate its running filesystem.

Follow an artifact through delivery

A release record should connect source commit, build inputs, tests, architecture, and selected image identity. Rebuilding the same commit later can produce different bytes if base tags or dependencies move. To promote a tested release, select the same tested artifact for the next environment and supply that environment's runtime configuration separately.

A real registry push requires an intended repository and an identity permitted to publish. Use scoped credentials and the registry's supported login flow. A credential helper stores credentials differently from pasting them into command arguments; neither grants permission by itself. This exercise stays local and needs no registry account.

On Apple Silicon, a native build is commonly ARM64. An AMD64 deployment needs a compatible image or supported emulation. A multi-platform build packages alternatives but does not prove both have been exercised. Inspect the target platform and test behavior there before claiming compatibility.

Checkpoint and next step

If :latest is deployed, can you infer it is the newest approved release? No; it is just a tag. If local tests pass on one image but CI rebuilds from an unpinned base, did CI necessarily produce those same bytes? No. Record observations rather than filling an evidence field with an example digest.

Write a small record for the fixture with its Dockerfile, source change, platform, local image ID, and the checks actually run. Mark the registry digest “not published” where appropriate. Next, separate build tools from runtime files without losing the ability to verify the resulting application.

References: image digests↗, image tag↗, multi-platform builds↗, and registry login↗.