Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-20T11:20:59.190Z
Answers: 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
Answers: user16635
Answers: CC BY-SA 4.0
Answers: 2019-08-20T11:40:21.190Z
Answers: @user16635 - please see my edit
Answers: profesor79
Answers: CC BY-SA 4.0
Answers: 2019-08-20T11:44:35.040Z
Answers: 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
Answers: user16635
Answers: CC BY-SA 4.0
Answers: 2019-08-20T11:46:25.260Z
Answers: 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
Answers: profesor79
Answers: CC BY-SA 4.0
Answers: 2019-08-20T10:52:30.793Z
Answers: 2019-08-20T11:40:06.240Z
Answers: 2019-08-20T11:40:06.240Z
Answers: profesor79
Body: <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>
  
Tags: <docker><gitlab><gitlab-ci-runner><docker-registry>
Title: CI pipelines, concurrency and build results possibly overwriting each-other
UserDisplayName: user16635
ThreadText: # 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](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-environment-variables-reference) `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](https://forums.docker.com/t/simple-script-needed-to-delete-all-docker-images-over-4-weeks-old/28558/7)
  
  > **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  
  
  ---
  
  