QA (public) » openQA Project (public)

This was not what I expected. The issue is of course with the non-ascii character inside overview.scss, where we have

        &:first-child:before {
            content: "•";
        }

The issue can be reproduced with podman:

podman run --rm -ti opensuse/leap:15.6 bash -c 'zypper ar -p 95 -f http://download.opensuse.org/repositories/devel:openQA/15.6 devel_openQA && zypper ar -p 90 -f http://download.opensuse.org/repositories/devel:openQA:Leap:15.6/15.6 devel_openQA_Leap && zypper --gpg-auto-import-keys ref && zypper in -y ca-certificates-mozilla curl openQA-local-db apache2 apache2-utils hostname which w3m "rubygem(sass)>=3.7.4" && cd /usr/share/openqa/assets && sass -I . stylesheets/openqa.scss'

What is the funny part, it is just the sass reading the locale and deciding not to use UTF-8 support (the default locale in the container is POSIX), so just adding LC_ALL=C.UTF-8 into the environment is enough to make this issue go away.

I will make the appropriate PR for our Dockerfiles, but I am not entirely sure if we should address that issue in some other way?

Dependency cron is also failing with sass related errors: https://github.com/os-autoinst/openQA/pull/608
There is no error output though.
https://app.circleci.com/pipelines/github/os-autoinst/openQA/15394/workflows/19fbb4e8-4e14-477e-9620-87dc9f7f8639/jobs/147523

[04:48:30] t/43-scheduling-and-worker-scalability.t .. [Pipe::Sass] Could not compile "stylesheets/dependency_graph.scss" with opts={"include_paths" => [bless( do{\(my $o = "/home/squamata/project/assets/stylesheets")}, 'Mojo::File' ),bless( do{\(my $o = "/home/squamata/project/assets")}, 'Mojo::Home' )]}:  at /usr/lib/perl5/vendor_perl/5.26.1/Mojolicious/Plugin/AssetPack/Pipe/Sass.pm line 70.
[04:48:30] t/43-scheduling-and-worker-scalability.t .. 1/? 
#   Failed test 'sub process openqa-webapi terminated with exit code 65280'
#   at /home/squamata/project/t/lib/OpenQA/Test/Utils.pm line 209.
# Looks like your test exited with -1 just after 2.

I can reproduce this locally with the new AssetPack module. I think it's actually doing too much error handling, see https://github.com/mojolicious/mojo-assetpack/pull/154/files#r1893955797

Can you provide me steps to reproduce? Is it just reproducible in the CircleCI container? I was not able to reproduce locally in a standard Tumbleweed container.

I installed the newest module locally and ran one of the tests:

cpanm -l local Mojolicious::Plugin::AssetPack
export PERL5LIB=$PWD/local/lib/perl5
rm -rf .sass-cache/* assets/cache/*
make test TESTS=t/43-scheduling-and-worker-scalability.t

I'm on Leap 15.6

Thanks! Will check and investigate.

if I do make test TESTS=t/43-scheduling-and-worker-scalability.t IPCRUN3DEBUG=1 I get:

run3(): running '/usr/bin/sass' '-s' '--trace' '-I' '/home/jbaier/Projects/openQA/assets/stylesheets' '-I' '/home/jbaier/Projects/openQA/assets' '--scss' '-t' 'compressed'
run3(): $? is -1

which seems like there really is some problem running the sass inside the tests

I also did some debugging and it turns out that any IPC::Run3::run3 command (even successful) will set $? to -1 as soon as _setup_sigchld_handler in t/lib/OpenQA/Test/Utils.pm was called.

Maybe we can workaround that by calling ./tools/generate-packed-assets before running the tests. This succeeds for me.

This patch helps:

diff --git a/lib/OpenQA/Assets.pm b/lib/OpenQA/Assets.pm
index 5b2b33e8d..4f0ac0c93 100644
--- a/lib/OpenQA/Assets.pm
+++ b/lib/OpenQA/Assets.pm
@@ -20,6 +20,7 @@ sub setup ($server) {
     $server->asset->store->retries(5) if $Mojolicious::Plugin::AssetPack::VERSION > 2.13;

     # -> read assets/assetpack.def
+    local $SIG{CHLD};
     eval { $server->asset->process };
     if (my $assetpack_error = $@) {    # uncoverable statement
         $assetpack_error    # uncoverable statement

Yeah, for some reason (which starts to look like a perl magic for me), the code from IPC::Run3

          my $r = ref $cmd
                ? system { $cmd->[0] } is_win32 ? quote_native( @$cmd ) : @$cmd
                : system $cmd;

is setting $r==0 and $?==-1 inside our tests.

...

Fiddling with child related signals might help :)

setting it explicitly to $SIG{CHLD} = 'DEFAULT'; also helps (of course); in the test we have _setup_sigchld_handler which changes the handler to $SIG{CHLD} = $SIGCHLD_HANDLER; and that messes up with the IPC::Run3 module; now it all makes sense :)