4

of course I am aware, that single jobs run in sequence FIFO if these jobs are pointing to a single runner, so they have to wait.

That is fine.

For a test environment, where we can only deploy & test one version at a time, we need not only single jobs to be queryed, but whole pipelines.

To be clear: If we have Job_Deploy & Job_Test which are Part of a Pipeline Pipeline, we need to wait for the whole pipeline to be done.

By now we have the scenario, that the sequence can possible not be in order:

Job_Deploy1, Job_Deploy2, Job_Test2, Job_Test1 may be the case.

But we need it strict FIFO

Pipeline1(Job_Deploy1, Job_Test1), Pipeline(Job_Deploy2, Job_Test2)

How can we achieve this?

Why do we seem to be alone with this requirement? Do we have any wrong perceptions here? Is it best practice? If not: why?

Best regards

Chris Pillen
  • 810
  • 8
  • 27

2 Answers2

2

Try Edit an existing resource group with process_mode oldest_first

https://docs.gitlab.com/ee/api/resource_groups.html#edit-an-existing-resource-group

Ertuğrul Altınboğa
  • 2,187
  • 4
  • 17
  • 25
-1

It seems like i misread the question and my initial answer is not applicable, i leave it at the end.

Right answer:

Use resource_group to create a resource group that ensures a job is mutually exclusive across different pipelines for the same project.

There are are so called resource_groups which you can use to force a certain order. and which ensures that jobs only run after each other even if they are in separate pipelines.

https://docs.gitlab.com/ee/ci/yaml/#resource_group

Wrong answer:

What you are looking for is the needs directive.

It offers you the possibility to express job dependencies within your ci file.

Something like

deploy1:
  script: echo "deploy 1"

test1:
  script: echo "test 1"
  needs:
    - deploy1

This means that test1 even if it is in the same stage, will not start as long as deploy1 has finished. Furthermore, you could also add needs: [] to deploy1 to start it immediately even if it is in a later stage. needs is powerful and allows you to work outside the stage boundaries.

Take a look at https://docs.gitlab.com/ee/ci/yaml/#needs

Simon Schrottner
  • 4,146
  • 1
  • 24
  • 36
  • Hey, thanks for answering. Sorry for answering late. It seems not to be the solution. The thing is: It solves, that PipeA.JobX never runs parallel to PipeB.JobX, that is right. But it does not guarantee: That PipeB.JobX waits for PipeA to finish with JobX, than JobY and than JobZ, doen't it? – Chris Pillen Mar 12 '22 at 15:55