I've recently hooked our CI servers up to build docker images upon git commit.

We have about 8 different containers that get built, each with their own language / frameworks. Some are node and have a package.json, others are python services that contain no semantic version information.

My question is not about how to create tags, its about creating the values for the tag.

How to ensure that each tag has a unique semantic version number for the specific images? Who should be the authority on tracking / incrementing a build version?

  • What is your current approach for creating the tags?
    – 030
    Oct 15, 2017 at 11:49
  • It is heard to see what you are asking. You say "semantic version number", which must be human asigned (our A.I.s are not advanced enough to decide the semantics of a commit just yet...). But then you ask about "incrementing a build version". What, then, are you actually interested in? Do you which to make sure the stuff just "increments" (like a SCN/system change number or whatever)? Or are you interested in the semantic content of the version number (i.e., whether it has incompatible changes)?
    – AnoE
    Nov 14, 2017 at 21:41

3 Answers 3


I would direct you to my post Coupling docker registry and source control where dmaze answered from the official forums.docker.com. Commit hash and branch name or tags suffices.

In your Dockerfile, use a LABEL to record the source of the build. That probably includes the commit hash from distributed source control (git, Mercurial), the branch name if relevant, any release tags if present, and possibly details like the timestamp of the last commit. docker history and docker inspect should be able to show these.

When you docker push your images, push them at least twice, with the commit hash and with the branch name as the “version” part (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test). If release tags are readily available, the CI system should push images with these tags too.

We are currently using a combination of branch name/commit hash. For us that seems to be enough. timestamps while they are useful IMO just add clutter as they don't provide anything the commit hash doesn't.

I agree with 030 regarding:

who should be the authority on tracking / incrementing a build version

100% is responsibility of the CI to maintain such things, with proper communication between other teams.

  • Why do you say that the timestamp doesn't matter? If you build the same Dockerfile and same git commit at different times, you may get different images (e.g. the base image may change over time to include security patches)
    – collimarco
    Nov 5, 2021 at 19:32

How to ensure that each tag has a unique semantic version number for the specific images?

One could create a tag that consists of multiple elements, e.g. a combination of a timestamp, git commit hash and semantic version. The latter has to be set manually, while the first two could be automated. Such a tag could look as follows:


This tag contains the date of build, the commit and the semantic version. If a docker image runs in production and a bug is found then one knows the version of the product, the code that is inside and when the image was built and under what circumstances.

Who should be the authority on tracking / incrementing a build version?

In my opinion this should be the responsibility of the CI as this is able to automate processes and as the creation of tags could be automated such a tool is the right tool for the job.


I suppose that you use one of the DevOps tools for CI/CD like Jenkins, I suggest the following approach,

If you use something like Jenkins-

  • You can configure your job such a way that you can use Jenkins environment variable "BUILD_ID", which retrieves the build id of the job when triggered to tag it to your image. This way you can version control your docker images. Please check the below example.

ex:- sudo docker build -t <image_name>:<BUILD_ID>

So, if you have got tag like mechanism for your SCM, you can check the tag in the respective build ID either in job based builds or in config.xml of the build ID in JENKINS HOME_FOLDER.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.