On Thu, 2021-01-14 at 12:03 +0100, Erik Skultety wrote:
'rules' syntax replaces the only/except syntax with which it
is
mutually exclusive. In some cases the 'rules' syntax is more readable
than the 'only/except' equivalent, in some cases it is not.
The idea behind this conversion is to introduce an explicit env variable
controlling the 'allow_failure' attribute which would be then attached
to a broken build job which would mark this broken build as a soft
failure which is not possible with the 'only/except' syntax.
Yes, the alternative here is to use 'allow_failure' directly on the
broken job, but being explicit is always better for readability than
implicit.
The changes are good, but the motivation you give here is bogus.
Please just drop this paragraph.
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
.gitlab-ci.yml | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 018008ca1c..de6ead01d8 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -43,6 +43,8 @@ stages:
.native_build_job_template:
stage: builds
image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
+ rules:
+ - when: on_success
According to
https://docs.gitlab.com/ee/ci/yaml/#when
when:on_success is the default, so I don't see the reason to have a
rules: section in this case. More instances of this further down.
Looks good otherwise.
--
Andrea Bolognani / Red Hat / Virtualization