I have a trigger for the master branch that tags images as :master, and another trigger on all tags that tags to :latest, so my :latest images are the latest tag, so that I can sort of guarantee that :latest is stable and :master is master’s HEAD.
This is on the Docker Hub, Quay.io does this by default if you leave the default build trigger on.
(I also have a third trigger that tags images with the name of the tag ifself, too)
This kind of thing is underappreciated. It’s amazing how badly things can go if you don’t have confidence in knowing precisely what version is deployed—not just for debugging, but also for operational issues, incident analysis, and even work tracking!
I have heard (but not verified) that Docker Hub at least doesn’t consistently keep untagged images permanently available, so old versions can disappear.
Hm. Seems overkill. I just tag my docker images with the git hash. Done. Don’t deploy
latest, deploy the tag.I have a trigger for the
masterbranch that tags images as:master, and another trigger on all tags that tags to:latest, so my:latestimages are the latest tag, so that I can sort of guarantee that:latestis stable and:masteris master’s HEAD.This is on the Docker Hub, Quay.io does this by default if you leave the default build trigger on.
(I also have a third trigger that tags images with the name of the tag ifself, too)
This kind of thing is underappreciated. It’s amazing how badly things can go if you don’t have confidence in knowing precisely what version is deployed—not just for debugging, but also for operational issues, incident analysis, and even work tracking!
The overkill (and much more secure) way of doing this is referencing images by digest:
image: quay.io/ricardbejarano/nginx@sha256:{SHA256_DIGEST}I believe this is standard for all registries, and at least I’ve made it work on both Docker and Kubernetes (CRI: containerd).
I have heard (but not verified) that Docker Hub at least doesn’t consistently keep untagged images permanently available, so old versions can disappear.