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.
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.
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 https://gitlab.com/gitlab-org/gitlab/.
This is the place where all development is done and all issues are created, both for CE and EE.
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.
rules:
- 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.
