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@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