I think what you want would be a DAG implementation of you GitLab CI pipeline.
That way it's possible to add dependencies between jobs in order to create a acyclic graph.
minimal example:
stages:
- a
- b
foo:
stage: a
when: manual
allow_failure: true
script:
- echo "hello world"
faa:
stage: a
when: manual
allow_failure: true
script:
- echo "hello world"
bar:
stage: b
needs:
- job: foo
optional: true
- job: FAA
optional: true
script:
- echo "hello world"
This way second stage would start its execution if any of the previous stages jobs would pass, but I think this might still not be what you exactly want.
So considering your pipeline execution would contain two jobs in stage A, the example provided by me would only run jobs from second stage if both dependent jobs from A succeed.
If any of the jobs is omitted and not put into the pipeline this would still work, as the dependencies are optional, but - and this is the main point - if any dependencies are specified and the corresponding jobs are part of one pipeline execution the needs
will make a logical AND so all dependencies need to be fulfilled before starting the job.
If you can guarantee that one job from stage A will always be part of your pipeline you could still add this one as dependency.
If your stage B does not even rely on the previous stage there is also the possibility to provide an empty needs array, which would be equal to "start this job right away - without any regard which stage comes first"
# this job would start at the same time as jobs in stage a
job-def:
stage: b
script:
- echo "hello world"
needs: []
a
jobs finishing and kicking off stageb
, but you can use theneeds
keyword to start a stageb
job when a specific job from stagea
finishes. So in the example I posted, there are two jobs in thebuild
stage, butlinux:test
in thetest
stage can start whenlinux:build
is done, but beforemac:build
is done (or vice versa). If a jobneeds
more than one job, both previous jobs need to be completed before this job will start. Needs lets you start stages before previous stages fully complete, but it looks like it's an AND not OR. – Eddybar
job might look like ``` bar: stage: b needs: foo ``` With this, bar will start as soon as foo finishes, regardless of faa's state. Not exactly your use case, but perhaps it helps? – Eddy