QA » openQA Project » openQA Tests

Taking a look in the ticket again: I think it is still valid however the scenario does not fail in the same way anymore. Please keep in mind that the category is "Enhancement to existing tests". The idea was to improve the failing test to make the problem more obvious, e.g. fail early with an explicit message

I think, the fact that only "minimal install" was available at that time was a rare product bug, or that the iso image that was used had been wrongly labelled ( as if we had inserted the wrong dvd ) so therefore the default choice was not the expected. So I think we could just close this ticket with this.

However, we could improve the way it currently works

In the case of these failures, the variable SYSTEM_ROLE was set to default, the test does not try to select anything if the role is set to default.

assert_screen('system-role-default-system', 180);
my $system_role = get_var('SYSTEM_ROLE', 'default');
change_system_role($system_role) if (get_var('SYSTEM_ROLE') && !check_var('SYSTEM_ROLE', 'default'));

In latest runs, the system_role is not set, so that type of error would not get detected either, we'd just select the default entry and go ahead.

So for the first solution that is mentioned in description, the system_role should be set explicitly to "gnome", not default or null. And we should create two needles tagged with "system-role-gnome(-selected)".
I think this solution is simpler than the second one, which would involve to re-factor installation_overview to detect many different cases and create as many needles.

Just a note : here is what we get in y2log while going back and forth in the "select role" module and selecting the different options. This could be used for defining the system roles in advance in Openqa.

# grep "Applying system role" y2log 
2019-03-05 08:54:44 <1> install(3345) [Ruby] installation/select_system_role.rb:209 Applying system role 'server'
2019-03-05 09:34:04 <1> install(3345) [Ruby] installation/select_system_role.rb:209 Applying system role 'generic_desktop'
2019-03-05 09:38:22 <1> install(3345) [Ruby] installation/select_system_role.rb:209 Applying system role 'gnome'
2019-03-05 09:45:51 <1> install(3345) [Ruby] installation/select_system_role.rb:209 Applying system role 'kde'
2019-03-05 09:46:49 <1> install(3345) [Ruby] installation/select_system_role.rb:209 Applying system role 'serverro'

PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6977

VRs done on production, all good.
https://openqa.suse.de/tests/2537188
https://openqa.suse.de/tests/2537189
https://openqa.suse.de/tests/2537187

PR (2nd try): Detect systemd target in installation_overview

Test failing: https://openqa.suse.de/tests/2706786
DESKTOP is set to gnome, but then at some point it gets magically changed to textmode.
[2019-03-22T13:10:36.213 CET] [debug] BUG: bsc#1058071 - No VNC server available in SUT, disabling X11 tests. Re-enable after bug is fixed
[2019-03-22T13:10:36.213 CET] [debug] usingenv DESKTOP=textmode

Comes from https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/products/sle/main.pm#L142

PR: Use record_info instead of die -> Merged

VR: sle-15-SP1-allmodules+allpatterns (re-triggered one job failing previously)
It detect the problem but the info box is empty. You might want to fix record_info parameters, first param is a short message (a few characters displayed in the box), and the other one where you put your message, probably is in the logs, but as we need to take a a look to many jobs, I guess it worth to fix it.

We might not see all those info boxes if some build has not recently triggered, therefore searching for them could be part of next ticket.

There is a problem with remote installations.
We are switching to install the console on the controller, which is a SUT with already installed OS.
I guess, we should omit this check, or change console using chvt [NUM] on remote installations.

• remote_ssh_controller@64bit

• remote_vnc_controller@64bit

• REMOTE_CONTROLLER={ssh,vnc}

Thanks @mloviska, I will add that info to the follow-up ticket. Ok, I got it now, it is a break, so we need to fix it now.

PR: Fix record_info in installation_overview -> Merged