<blockquote>
  <p>How to ensure that each tag has a unique semantic version number for
  the specific images?</p>
</blockquote>

<p>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:</p>

<pre><code>20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4
</code></pre>

<p>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.</p>

<blockquote>
  <p>Who should be the authority on tracking / incrementing a build
  version?</p>
</blockquote>

<p>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.</p>

CC BY-SA 3.0
2017-10-15T12:21:14.683Z
2017-10-15T12:21:14.683Z
030
<p>I suppose that you use one of the DevOps tools for CI/CD like Jenkins, I suggest the following approach,</p>

<p>If you use something like Jenkins-</p>

<ul>
<li>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.</li>
</ul>

<p>ex:- <code>sudo docker build -t &lt;image_name&gt;:&lt;BUILD_ID&gt;</code></p>

<p>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.</p>

CC BY-SA 3.0
2018-03-23T02:25:06.770Z
2018-03-23T02:25:06.770Z
Tezi
<p>I would direct you to my post <a href="https://devops.stackexchange.com/questions/3334/coupling-docker-registry-and-source-control/3342?noredirect=1#comment4866_3342">Coupling docker registry and source control</a> where dmaze answered from the official <a href="https://forums.docker.com/t/coupling-docker-registry-with-scm/46199" rel="noreferrer">forums.docker.com</a>.  Commit hash and branch name or tags suffices.</p>
<blockquote>
<p>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.</p>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>I agree with <strong>030</strong> regarding:</p>
<blockquote>
<p>who should be the authority on tracking / incrementing a build version</p>
</blockquote>
<p>100% is responsibility of the CI to maintain such things, with proper communication between other teams.</p>

CC BY-SA 4.0
2021-11-05T19:32:04.720Z
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
CC BY-SA 3.0
2018-02-20T20:11:10.043Z
2018-02-20T20:11:10.043Z
2020-06-18T08:28:10.803Z
scott
<p>I've recently hooked our CI servers up to build docker images upon git commit. </p>

<p>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. </p>

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

<p>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?</p>

CC BY-SA 3.0
2017-10-15T11:49:35.717Z
What is your current approach for creating the tags?
030
CC BY-SA 3.0
2017-11-14T21:41:19.640Z
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
<docker><continuous-integration><versioning>
What are best practices for docker tag versioning?
Jack Murphy
# What are best practices for docker tag versioning?

(Asked by: username_0 on 2017-07-10)

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?

**Tags:** docker, continuous-integration, versioning

> **Comments:**
> **username_1**: What is your current approach for creating the tags?  
> **username_2**: 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)?  

---

## 3 answers

### Answer by username_4 on 2018-02-20. Score: 7 | Accepted answer

I would direct you to my post [Coupling docker registry and source control](https://devops.stackexchange.com/questions/3334/coupling-docker-registry-and-source-control/3342?noredirect=1#comment4866_3342) where dmaze answered from the official [forums.docker.com](https://forums.docker.com/t/coupling-docker-registry-with-scm/46199). 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 **username_1** 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.

> **Comments:**
> **username_5**: 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)  

---

### Answer by username_1 on 2017-10-15. Score: 2

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:
20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

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.


---

### Answer by username_3 on 2018-03-23. Score: 1

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 :`

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.


---

