Image names and tags
Image tags give your container images short names, so you can say v3 and still know exactly which image a job used.
A tag is a label such as v3 that points to one version of an image. When a booking locks, Hangar looks up the version that the tag points to at that moment. The job uses that version. If you rebuild the image later, the job does not change.
This page covers hangar image tag, and how Hangar turns a name and a tag into a digest when a booking locks.
Reserved names
The name quarantine, and every name under quarantine/, belong to the platform's serving images. A push, a tag or a pull to such a name gets image_name_invalid.
Serving images belong to the Hangar platform, not to an organisation. They are held in the platform's own store, apart from the registry of every organisation. The names in your organisation stay yours: a push, a tag, a pull and a job in your organisation read only your organisation's registry. You can push and run an image named trn2-serve, whatever the platform's serving images are named, and a job that names an image your organisation does not hold gets image_unresolved (422).
Version tags never move
A version tag is three numbers separated by dots, such as 1.2.0. Once a version tag names a digest, the tag names only that digest, in every organisation. A push completion or hangar image tag that gives a version tag another digest gets tag_immutable (409), also after the image was removed. The detail of the error names the digest that the version names now. To publish a changed image, push the image as the next version, such as 1.2.1. The same digest again succeeds and leaves the image as it is.
latest, a branch name and every other tag move: a push or hangar image tag points the tag at the new digest. A tag that looks close to a version, such as 1.2, v1.2.0 or 1.2.0-rc1, also moves.