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