On Thu, Jan 14, 2021 at 12:45:40PM +0100, Andrea Bolognani wrote: > 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. I'm adding the rule in the next patch, I didn't want to put it in the next though to prevent potential confusion. In this patch it's a NOP, in the next one it will matter though, because if no rule matches the default action is that the job is not going to be added to the pipeline, so you need a top level 'when' to make sure that if no rule matches the job is still selected for the pipeline. Erik
