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

1 Answer 1


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


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

  • 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
    Aug 20, 2019 at 11:20
  • @user16635 - please see my edit
    – profesor79
    Aug 20, 2019 at 11:40
  • 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
    Aug 20, 2019 at 11:44
  • 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
    Aug 20, 2019 at 11:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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