Project

General

Profile

action #56777

coordination #56267: [epic][qe-core][functional] openSUSE welcome message is not properly handled

[functional][u] test fails in installation - openSUSE Welcome not handled in installation module after autoyast

Added by StefanBruens about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 28
Start date:
2019-09-11
Due date:
% Done:

0%

Estimated time:
42.00 h
Difficulty:

Description

Observation

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-autoyast_gnome@64bit fails in
installation

Acceptance criteria

  • AC1: There is a function to check and close the openSUSE welcome popup when a user logs in in a graphical session.
  • AC2: The function is properly used in scenario opensuse-Tumbleweed-DVD-x86_64-autoyast_gnome@64bit (this removes urgency)
  • AC3: The function is properly used in any openSUSE scenario where a user logs in in a graphical session (Tumbleweed, JeOS, KDE, GNOME, IceWM, etc)

Tasks

  • Create the function as opensusebasetest.pm method.

Reproducible

Fails since (at least) Build 20190909 (current job)

Expected result

Last good: 20190907 (or more recent)

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #38423: [sle][functional][u][hard] Refactor first_boot to unify duplicated behavior for remote backendRejected2018-07-16

History

#1 Updated by SLindoMansilla about 3 years ago

  • Subject changed from test fails in installation - openSUSE Welcome not handled to [functional][u] test fails in installation - openSUSE Welcome not handled in installation module after autoyast
  • Parent task set to #56267

#2 Updated by SLindoMansilla about 3 years ago

  • Related to action #38423: [sle][functional][u][hard] Refactor first_boot to unify duplicated behavior for remote backend added

#3 Updated by SLindoMansilla about 3 years ago

The module installation is doing both the work of wait_install and first_boot. If the behavior would have been done separately, the issue could be resolved by just scheduling the module opensuse_welcome.

#4 Updated by SLindoMansilla about 3 years ago

  • Priority changed from Normal to High

#5 Updated by SLindoMansilla about 3 years ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Priority changed from High to Urgent
  • Target version set to Milestone 28
  • Estimated time set to 42.00 h

#6 Updated by zluo about 3 years ago

  • Status changed from Workable to In Progress
  • Assignee set to zluo
  • Priority changed from Urgent to High

take over and check current status.

#7 Updated by zluo about 3 years ago

failing all the time till now except a month ago:

https://openqa.opensuse.org/tests/1048228#step/installation/18

#8 Updated by zluo about 3 years ago

  • Priority changed from High to Urgent

okay, keep P: urgent

#9 Updated by StefanBruens about 3 years ago

The first step is solved by
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8413/files

It is sufficient to pass the test.

If any further handling is required, it can be added instead of the return;:

elsif (match_has_tag('opensuse-welcome')) {
    return;   // <- Change if further handling is required
}

#10 Updated by zluo about 3 years ago

http://f40.suse.de/tests/5270 shows successful results by using PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8413

Tumbleweed-DVD-x86_64-Build20191104-autoyast_gnome: OK

#11 Updated by zluo about 3 years ago

restart some autoyast tests on o3 and check these test results later.

#12 Updated by zluo about 3 years ago

  • Status changed from In Progress to Resolved

#13 Updated by SLindoMansilla about 3 years ago

  • Priority changed from Urgent to High

#14 Updated by SLindoMansilla about 3 years ago

  • Status changed from Resolved to Workable

Acceptance criteria are not fulfilled.

It is a matter of time until another module in another scenario fails again and then we have a lot of microcode spread on every module for graphical session. Just passing is not an option. We have also cases where other needles fail due to the window. Remember the click to close window when a background window matches in gnucash. And now we are are letting this race condition happen on any module.

The openSUSE welcome popup needs to be handled properly:
Closed the first time it appears with checkbox "Show on next startup" out.

In this autoyast scenario, this has to be handled here: http://f40.suse.de/tests/5270#step/installation/10

So that the popup doesn't appear in any of the following modules:

#15 Updated by zluo about 3 years ago

  • Status changed from Workable to In Progress

okay, add handling for 'don't show for next startup' and 'close':

http://f40.suse.de/tests/5271#step/installation/13

#16 Updated by zluo about 3 years ago

  • Status changed from In Progress to Feedback

#17 Updated by zluo about 3 years ago

aarch64 verification test:
https://openqa.opensuse.org/tests/1083327 shows issue for openqa-clone-custom-git-refspec

check then: http://f40.suse.de/tests/5290

#18 Updated by zluo about 3 years ago

  • Status changed from Feedback to In Progress

#20 Updated by zluo about 3 years ago

to check https://openqa.opensuse.org/tests/1083432 with patched openqa-clone-custom-git-refspec

#21 Updated by zluo about 3 years ago

  • Status changed from In Progress to Feedback

#22 Updated by zluo about 3 years ago

https://openqa.opensuse.org/tests/1084333 excludes now module opensuse_welcome.

#23 Updated by SLindoMansilla about 3 years ago

PR merged.

Also available in: Atom PDF