<p>If you want a beautiful integration between Docker and SCM, GitLab provides it's own built-in Docker registry. This makes publishing a Docker image in the build pipeline a breeze.</p>

<p>The other big advantage of GitLab Docker registry is that it supports multiple Docker repositories for each GitLab repo. This allows you to create a new Docker repo for each branch, or each commit, each environment, or anything you need.</p>

<p>My company leverages this by pushing our images to repos based on the branch, tagged with their commit. Here is an example: <code>project-name/branch-name:commit-SHA</code></p>

<p>Or if you have multiple Docker images being build for a particular branch (like a front-end Angular app and it's back-end API that it talks to), you can scope it even further, like so:<br>
<code>project-name/branch-name/api:commit-SHA</code><br>
<code>project-name/branch-name/front-end:commit-SHA</code></p>

<p>There are no limits to the number of slashes (/) you can use for scoping. This makes it very easy to tell the exact commit of an image when it's deployed. For this reason, my company almost never uses the generic 'latest' tag. We prefer the specificity of which image is deployed where.</p>

<p>You can still apply this same 'multiple docker repo' logic to any Docker registry. You'll have to look up that specific system's capabilities for creating new repos on the fly, and how easy it is to integrate with your CI/CD pipeline.</p>

CC BY-SA 4.0
2023-09-07T08:25:50.257Z
FYI Docker Public registry recommends 2 slash-separated components,  see **PATH**: https://docs.docker.com/engine/reference/commandline/tag/#description Some public registries only support 2 slash-separated components. Apparently the spec does not impose a limit. We're using Sonatype Nexus Repository, which does support more than 2 slash-separated components, so for a private repo, you can certainly do this.
ptha
CC BY-SA 3.0
2018-02-21T17:56:53.787Z
2018-02-21T17:56:53.787Z
BoomShadow
<p>I was able to get an answer over here <a href="https://forums.docker.com/t/coupling-docker-registry-with-scm/46199" rel="nofollow noreferrer">forums.docker.com</a> Credit goes to dmaze.</p>

<p>Set up some sort of automated build system (“continuous integration” in the current trendy term). Docker is sufficiently mainstream at this point that any of the cloud-based or locally-installed CI systems can do it.</p>

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

<p>Make sure the Dockerfile is committed to source control, of course, and try to have a stable path to get any external dependencies that may be present.</p>

<p>Now you can go both ways: given an arbitrary commit, if your CI system built it, you can docker run the image it built; and if you have an image, you can find where exactly in source history it came from, and git checkout or hg up to that specific version, and docker build a near-identical copy of it yourself.</p>

CC BY-SA 3.0
2018-02-14T23:23:16.603Z
Is there a difference when pushing docker multiple times?
Moritz
CC BY-SA 3.0
2018-02-15T21:11:16.027Z
not sure of your question but the docker registry will keep track of the image's hash so if you push a docker image multiple times (with different tags) you will get multiple 'image names' with the tags but they all reference the same hash.. so no extra space is taken except that to store the new image name.
scott
CC BY-SA 3.0
2018-02-13T15:46:17.530Z
2018-02-13T15:46:17.530Z
scott
<p>What are the best practices (if any) for coupling a docker image registry with a SCM service (such as bitbucket)?</p>

<p>I know a docker registry can live in <a href="https://www.jfrog.com/confluence/display/RTF/Docker+Registry" rel="noreferrer">artifactory</a>, but how can I assure that the two are as tightly coupled as possible?  </p>

<p>For example I am worried that without due-diligence from developers the latest Docker image in the registry will not reflect the current state of the Dockerfile in SCM or vice-versa.  Also it is imperative that we can always trace back to the base Dockerfile (that we made) for any image in the registry.</p>

<docker><git><scm><registry>
Coupling docker registry and source control
scott
# Coupling docker registry and source control

(Asked by: username_0 on 2018-02-12)

What are the best practices (if any) for coupling a docker image registry with a SCM service (such as bitbucket)?

I know a docker registry can live in [artifactory](https://www.jfrog.com/confluence/display/RTF/Docker+Registry), but how can I assure that the two are as tightly coupled as possible?

For example I am worried that without due-diligence from developers the latest Docker image in the registry will not reflect the current state of the Dockerfile in SCM or vice-versa. Also it is imperative that we can always trace back to the base Dockerfile (that we made) for any image in the registry.

**Tags:** docker, git, scm, registry


---

## 2 answers

### Answer by username_0 on 2018-02-13. Score: 3 | Accepted answer

I was able to get an answer over here [forums.docker.com](https://forums.docker.com/t/coupling-docker-registry-with-scm/46199) Credit goes to dmaze.

Set up some sort of automated build system (“continuous integration” in the current trendy term). Docker is sufficiently mainstream at this point that any of the cloud-based or locally-installed CI systems can do it.

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.

Make sure the Dockerfile is committed to source control, of course, and try to have a stable path to get any external dependencies that may be present.

Now you can go both ways: given an arbitrary commit, if your CI system built it, you can docker run the image it built; and if you have an image, you can find where exactly in source history it came from, and git checkout or hg up to that specific version, and docker build a near-identical copy of it yourself.

> **Comments:**
> **username_3**: Is there a difference when pushing docker multiple times?  
> **username_0**: not sure of your question but the docker registry will keep track of the image's hash so if you push a docker image multiple times (with different tags) you will get multiple 'image names' with the tags but they all reference the same hash.. so no extra space is taken except that to store the new image name.  

---

### Answer by username_1 on 2018-02-21. Score: 5

If you want a beautiful integration between Docker and SCM, GitLab provides it's own built-in Docker registry. This makes publishing a Docker image in the build pipeline a breeze.

The other big advantage of GitLab Docker registry is that it supports multiple Docker repositories for each GitLab repo. This allows you to create a new Docker repo for each branch, or each commit, each environment, or anything you need.

My company leverages this by pushing our images to repos based on the branch, tagged with their commit. Here is an example: `project-name/branch-name:commit-SHA`

Or if you have multiple Docker images being build for a particular branch (like a front-end Angular app and it's back-end API that it talks to), you can scope it even further, like so:  
`project-name/branch-name/api:commit-SHA`  
`project-name/branch-name/front-end:commit-SHA`

There are no limits to the number of slashes (/) you can use for scoping. This makes it very easy to tell the exact commit of an image when it's deployed. For this reason, my company almost never uses the generic 'latest' tag. We prefer the specificity of which image is deployed where.

You can still apply this same 'multiple docker repo' logic to any Docker registry. You'll have to look up that specific system's capabilities for creating new repos on the fly, and how easy it is to integrate with your CI/CD pipeline.

> **Comments:**
> **username_2**: FYI Docker Public registry recommends 2 slash-separated components,  see **PATH**: https://docs.docker.com/engine/reference/commandline/tag/#description Some public registries only support 2 slash-separated components. Apparently the spec does not impose a limit. We're using Sonatype Nexus Repository, which does support more than 2 slash-separated components, so for a private repo, you can certainly do this.  

---

