diff options
| author | Daniel P. Berrangé <berrange@redhat.com> | 2022-05-27 16:35:58 +0100 |
|---|---|---|
| committer | Alex Bennée <alex.bennee@linaro.org> | 2022-06-01 15:47:43 +0100 |
| commit | 6a0e7ea7b87cfa684bbcebaebafaef14c29a8872 (patch) | |
| tree | e9605da014590e787d7acc0a664377b8b8b6725d /.gitlab-ci.d/base.yml | |
| parent | f21db42631ae1f3feaa3bf94edd9c06c24b4aeb6 (diff) | |
gitlab: introduce a common base job template
Currently job rules are spread across the various templates
and jobs, making it hard to understand exactly what runs in
what scenario. This leads to inconsistency in the rules and
increased maint burden.
The intent is that we introduce a common '.base_job_template'
which will have a general purpose 'rules:' block. No other
template or job should define 'rules:', but instead they must
rely on the inherited rules. To allow behaviour to be tweaked,
rules will be influenced by a number of variables with the
naming scheme 'QEMU_JOB_nnnn'.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220526110705.59952-2-berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220527153603.887929-29-alex.bennee@linaro.org>
Diffstat (limited to '.gitlab-ci.d/base.yml')
| -rw-r--r-- | .gitlab-ci.d/base.yml | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/.gitlab-ci.d/base.yml b/.gitlab-ci.d/base.yml new file mode 100644 index 0000000000..10eb6ab8bc --- /dev/null +++ b/.gitlab-ci.d/base.yml @@ -0,0 +1,28 @@ + +# The order of rules defined here is critically important. +# They are evaluated in order and first match wins. +# +# Thus we group them into a number of stages, ordered from +# most restrictive to least restrictive +# +.base_job_template: + rules: + ############################################################# + # Stage 1: exclude scenarios where we definitely don't + # want jobs to run + ############################################################# + + + ############################################################# + # Stage 2: fine tune execution of jobs in specific scenarios + # where the catch all logic is inapprorpaite + ############################################################# + + + ############################################################# + # Stage 3: catch all logic applying to any job not matching + # an earlier criteria + ############################################################# + + # Jobs can run if any jobs they depend on were successfull + - when: on_success |