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