Is it recommended and standard practice to re-build and push the image with same tag?
For eg: I have created an image with “1.1” tag, this image has some built in python package and libraries. After few days, I re-build the image without any code changes and push it with same “1.1” tag, this leads to overwrite of the image. Is it recommended to do so?
Mutable tags are often used for end user convenience, as they know as long as they pull the mutable tag and create a container from it, it should be that specific version. But it can also lead to inconvenience…
For instance docker and docker compose will not pull the updated image for a tag, if an image for it already exists in the local image cache. Kubernetes users might have configured a similar behavior with imagePullPolicy: IfNotPresent.
People might end up using a build of the image the tag had, at the point in time they used it the first time. They would need to specifically pull the image, so that next time a container is created from that tag, it bases on the new image.
In private, I prefer to provide mutable and immutable tags. The immutable tags are unique per build and are useful for those that need to control the exact version. Whenever it relates to a specific mutable tag, I update those as well.,
At the job: immutable tags all along, with rare exceptions
Thanks @meyay for reply
I understand the image pull part but I wanted to know is it industry standard to overwrite the same tag of the image?
Your takeaway from my last post should have been: it depends on the audience and use case. For example official images on Docker Hub usually have mutable and immutable tags. They cater to a broad range for consumers, starting from it enthusiast up to tech-savvy enterprises (that rarely use those images as they are).
In my experience enterprises typically have compliance policies that mandate immutable release artifacts set in stone (no update, no delete) 
At least that’s what the enterprises I worked for/with had over the last years. They typically have a high level of automation that takes care of creating meaningful unique version numbers, use DevSecOps pipelines to build and/or deploy, use mechanics for automated patch management, which also pins image tags to their digests. Almost everything happens without manual intervention. The created images are typically required to work with the restricted pod security standards - most of the images on Docker Hub fail to do so.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.