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
