How to prevent multiple pipelines from running at the same time

I want to stop any pipeline from executing until the previous one has finished for a particular tag.

For example, I have a dev runner and a prod runner, each taking care of dev test deployments and prod deployments.

I am already using limits but they dont work. They prevent concurrency (two jobs running at the same time), but they dont necesarily prevent two interleaved piplines from occuring on the same runner which totally messes with my deployment workflow that requirs singular resources.

eg dev pipeline 1 may be up to job 7/10 for that pipe, and dev pipeline 2 may start at some point when I really dont want that happening. same for a deployment in production. its a singular resource, and once a pipeline starts it should own that resource until succesful completion or failure. Definitely not allowing another pipe to jump in there and start over.

Here is a link to a dead ticket where amyn others put effort into this -

Like other issues I seem to find became a dead end for the gitlab-ce merge to gitlabb FOSS, and its been pretty frustrating in picking gitlab up. Most google results for any of my IAC question results in a dead end for me - almost everything I google terminates with the depressing

Hey! 👋
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. 

So what happenned to all the people that took the time to communicate and work on this problem int hat thread? Is it just gone? its not clear if there is a solution. Most issues seem to commonly have threads that were started 3 years ago, and still aren’t resolved today.

Thanks if anyone can shed some light on all this, I’d like to get gitlab to work for me.

1 Like

When the development of GitLab CE and EE moved to a single codebase, all issues were also moved.
The GitLab FOSS project is now read-only.

The new project is
This is the place where all development is done and all issues are created, both for CE and EE.

If you open issue you’ll see that it was closed.
It was closed in the GitLab FOSS project, but moved to the new project.

Click on the moved link and you’ll end up at
This is the original issue copied over from the CE project, and work continued on it.

The result is Resource groups released in GitLab version 12.7.

Thankyou Rev, I didnt realise when going through the thread too quickly that it had been implemented in January. That looks exactly what is needed! Thankyou for your help.

affter aplying this suggestion, I just had two commits on different branches run pipes interleaved again on the same runner, but they are both using the same resource group. here is an example of my job template, which is applied to all jobs

.job_template_dev: &job_definition_dev
  resource_group: dev
  dependencies: [] # we specify no dependencies so that artifacts dont all get aquired (default), which would orphan the tfstate file.
    - if: $all_manual =~ /true/ && $CI_COMMIT_BRANCH != "master" && $CI_COMMIT_BRANCH != "stage"
      when: manual
    - if: $single_stage == $CI_JOB_STAGE && $CI_COMMIT_BRANCH != "master" && $CI_COMMIT_BRANCH != "stage"
      when: always
    - if: $single_stage == 'disabled' && $CI_COMMIT_BRANCH != "master" && $CI_COMMIT_BRANCH != "stage"
      when: always
    - if: $destroy_on_failure == 'true' && $CI_JOB_STAGE == 'cleanup_terraform_destroy_dev' && $CI_COMMIT_BRANCH != "master" && $CI_COMMIT_BRANCH != "stage"
      when: on_failure
    - if: $manual == 'true' && $CI_COMMIT_BRANCH != "master" && $CI_COMMIT_BRANCH != "stage"
      when: manual
      allow_failure: true
  tags: # the runner is tagged dev
    - dev

This is a screenshot that shows two pipelines in the dev branch that should not have run interleaved, but they did. It doesn’t look like resource groups do anything here. the second pipeline was free to start when one job finished in the first, and it breaks the workflow, since the second pipeline should not be allowed to take the resource. I also tried renaming the resource_group to dev_resource in case there might have been a conflict with a common name like dev.

it looks like there is not a solution to this, or am I wrong? resource groups don’t resolve it.
I created a ticket -

1 Like