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