[libvirt PATCH 4/4] ci: Halt on sanitizer errors

[Tim Wiederhake]

On Wed, 2021-07-21 at 06:56 -0700, Andrea Bolognani wrote:
> On Wed, Jul 21, 2021 at 03:08:02PM +0200, Peter Krempa wrote:
> > On Wed, Jul 21, 2021 at 14:46:43 +0200, Tim Wiederhake wrote:
> > > +++ b/.gitlab-ci.yml
> > > @@ -89,6 +89,8 @@ stages:
> > >      - meson build --werror -Ddocs=disabled -Db_lundef=false -
> > > Db_sanitize="$SANITIZER"
> > >      - ninja -C build;
> > >      - ninja -C build test;
> > > +  variables:
> > > +    UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1
> > 
> > Is this being propagated as an env variable? In many cases in the
> > gitlab-ci there are entries doing 'export ENV=VAL' for some reason.
> 
> Setting environment variables as part of the script rather than using
> the native GitLab CI keyword is necessary to be able to use the same
> environment for multiple jobs: using something like
> 
>   .template:
>     variables:
>       FOO: foo
> 
>   job:
>     extends: .template
>     variables:
>       BAR: bar
> 
> would result in only $BAR being set for job, which is not what we
> want. We always use 'variables' where possible.
> 

I am not sure that I understand you correctly:

.gitlab-ci.yml:
    .template:
      variables:
        MARKER_FOO: foo
      script: "env | grep MARKER"
    
    job:
      extends: .template
      variables:
        MARKER_BAR: bar

Both "MARKER_FOO" and "MARKER_BAR" are set:
https://gitlab.com/twiederh/libvirt/-/jobs/1443690227

Here is a pipeline for a branch with only patch #4, which fails as
expected:
https://gitlab.com/twiederh/libvirt/-/pipelines/340558056

Is it possible that that Gitlab used to exhibit the behavior that you
describe, but it was fixed in the meantime?

Regards,
Tim