<p>I am using AzureDevOps and the trick we use when naming containers is to add build number to the label</p>

<pre><code>namespace/application:branch-name-bulidNumber
</code></pre>

<p>So in your case, you could try <a href="https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-environment-variables-reference" rel="nofollow noreferrer">gitlab variable</a> <code>CI_CONCURRENT_PROJECT_ID</code></p>

<h1>After comment</h1>

<p>for images clean-up you can use:</p>

<pre><code>  docker image prune --all --filter until=48h 
</code></pre>

<p>As docker system prune and docker image prune have the until filter. So docker image prune --all --filter <strong>until=48h</strong> would remove all (not just dangling) images that were created more than 48 hours ago. Hopefully that helps. <a href="https://forums.docker.com/t/simple-script-needed-to-delete-all-docker-images-over-4-weeks-old/28558/7" rel="nofollow noreferrer">source here</a></p>

CC BY-SA 4.0
2019-08-20T11:20:59.190Z
Thanks for the response, that is assuming that gitlab creates the build jobs in the right order as well! I may be looking wrong, but i cant find any documentation which guarantees that is always the case.

I'm also hoping to not append any extra details to the end of the image tag, as that is just more data that needs to be manually pruned from the registry
user16635
CC BY-SA 4.0
2019-08-20T11:40:21.190Z
@user16635 - please see my edit
profesor79
CC BY-SA 4.0
2019-08-20T11:44:35.040Z
Thanks for the quick response but that still doesnt solve the issue.
The problems i see doing this are:
1. A developer / devops person will need to inspect the build number, and the hash that relates to that build number to ensure that the latest code is about to be deployed, they cant just trust the tag name
2. that command is for clearing ALL images for a docker host, not the registry
3. Even if it was to clear images from the registry, you would loose images that you built (and probably still use) after 4 weeks, which is problematic in a production environment
user16635
CC BY-SA 4.0
2019-08-20T11:46:25.260Z
no problem @user16635. The only thing that I have in mind is to trigger one build when the first is finished. But I'm not sure is such build-chain will not give you more struggle with CI configuration
profesor79
CC BY-SA 4.0
2019-08-20T10:52:30.793Z
2019-08-20T11:40:06.240Z
2019-08-20T11:40:06.240Z
profesor79
<p>I'm currently using gitlab-ci to generate docker images for some repositories, however i dont feel as though this solution is as reliable as it should be.</p>

<p>I can forsee a issue with multiple builds happening close together and build #100 overwriting the newly built docker image produced by build #101, if for whatever reason jobs dont finish sequentially (eg: multiple build hosts, etc...).</p>

<p>Currently the tags i'm hoping to use follow this pattern:
<code>namespace/application:branch-name</code></p>

<p>The crux of the question is as follows:</p>

<ol>
<li>How do other services solve this problem? (presumibly running builds sequentially per branch?)</li>
<li>How should this issue be resolved in gitlab environments in a totally watertight manner</li>
</ol>

<p>I understand this problem would go away if i use the SHA of the commit for the build tag, but i'd like to stick to the branch name for the following reasons:</p>

<ul>
<li>orphaned / old images will be grabage collected by the docker registry</li>
<li>branch name is easier to use</li>
</ul>

<docker><gitlab><gitlab-ci-runner><docker-registry>
CI pipelines, concurrency and build results possibly overwriting each-other
user16635
# CI pipelines, concurrency and build results possibly overwriting each-other

(Asked by: username_0 on 2019-08-19)

I'm currently using gitlab-ci to generate docker images for some repositories, however i dont feel as though this solution is as reliable as it should be.

I can forsee a issue with multiple builds happening close together and build #100 overwriting the newly built docker image produced by build #101, if for whatever reason jobs dont finish sequentially (eg: multiple build hosts, etc...).

Currently the tags i'm hoping to use follow this pattern:
`namespace/application:branch-name`

The crux of the question is as follows:

1. How do other services solve this problem? (presumibly running builds sequentially per branch?)
2. How should this issue be resolved in gitlab environments in a totally watertight manner

I understand this problem would go away if i use the SHA of the commit for the build tag, but i'd like to stick to the branch name for the following reasons:

* orphaned / old images will be grabage collected by the docker registry
* branch name is easier to use

**Tags:** docker, gitlab, gitlab-ci-runner, docker-registry


---

## 1 answers

### Answer by username_1 on 2019-08-20. Score: 1

I am using AzureDevOps and the trick we use when naming containers is to add build number to the label
namespace/application:branch-name-bulidNumber

So in your case, you could try gitlab variable CI_CONCURRENT_PROJECT_ID
After comment
for images clean-up you can use:
  docker image prune --all --filter until=48h 

As docker system prune and docker image prune have the until filter. So docker image prune --all --filter until=48h would remove all (not just dangling) images that were created more than 48 hours ago. Hopefully that helps. source here

> **Comments:**
> **username_0**: Thanks for the response, that is assuming that gitlab creates the build jobs in the right order as well! I may be looking wrong, but i cant find any documentation which guarantees that is always the case.  I'm also hoping to not append any extra details to the end of the image tag, as that is just more data that needs to be manually pruned from the registry  
> **username_1**: @username_0 - please see my edit  
> **username_0**: Thanks for the quick response but that still doesnt solve the issue. The problems i see doing this are: 1. A developer / devops person will need to inspect the build number, and the hash that relates to that build number to ensure that the latest code is about to be deployed, they cant just trust the tag name 2. that command is for clearing ALL images for a docker host, not the registry 3. Even if it was to clear images from the registry, you would loose images that you built (and probably still use) after 4 weeks, which is problematic in a production environment  
> **username_1**: no problem @username_0. The only thing that I have in mind is to trigger one build when the first is finished. But I'm not sure is such build-chain will not give you more struggle with CI configuration  

---

