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:
> The undefined behaviour sanitizer (UBSAN) defaults to merely printing an
> error message if it detects undefined behaviour. These error messages often
> end up in captured output and do not fail the tests, effectively hiding
> the warning. Make the test cases fail to make the issues visible.
>
> Signed-off-by: Tim Wiederhake <twiederh(a)redhat.com>
> ---
> .gitlab-ci.yml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 3cb6ff5e6b..4757139fa9 100644
> --- a/.gitlab-ci.yml
> +++ 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.
Some of the exported variables rely on state provided by the shell
($pwd) or by the running container image ($CCACHE_WRAPPERSDIR), so
they canot be declared in the "variables:" block.
If this really results in env variables then:
Yes, it does.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|