action #56963
closed
test fails in opensuse_welcome - opensuse welcome dialog hasn't closed properly
Added by mlin7442 about 5 years ago.
Updated about 5 years ago.
Category:
Bugs in existing tests
Description
Observation¶
openQA test in scenario opensuse-Tumbleweed-NET-x86_64-zdup-Leap-42.3-gnome@64bit_cirrus fails in
opensuse_welcome
Test suite description¶
Reproducible¶
Fails since (at least) Build 20190909
Expected result¶
Last good: 20190907 (or more recent)
Further details¶
Always latest result in this scenario: latest
- Is duplicate of action #55661: [opensuse][u] test fails in several modules after booting and login - "openSUSE Welcome" not handled (WAS: test fails in first_boot) added
- Status changed from New to Rejected
Not openSUSE Welcome per se, but just another instance of "all input ignored".
- Is duplicate of deleted (action #55661: [opensuse][u] test fails in several modules after booting and login - "openSUSE Welcome" not handled (WAS: test fails in first_boot))
- Related to action #55661: [opensuse][u] test fails in several modules after booting and login - "openSUSE Welcome" not handled (WAS: test fails in first_boot) added
The module is bad implemented with loops with arbitrary iterations. It is just going to fail again for "missing input".
It is not a feature, it is a bug in tests. The work is not finished, so it still needs to be worked on, preferably on one ticket to avoid more horror stories.
So, rejecting this as not an opensuse_welcome problem is like "I have pushed my changes and works for me so I don't care if I haven't resolved the issue for others".
SLindoMansilla wrote:
The module is bad implemented with loops with arbitrary iterations. It is just going to fail again for "missing input".
It is not a feature, it is a bug in tests. The work is not finished, so it still needs to be worked on, preferably on one ticket to avoid more horror stories.
So, rejecting this as not an opensuse_welcome problem is like "I have pushed my changes and works for me so I don't care if I haven't resolved the issue for others".
No, the problem is the unreliable input. If the input were reliable, no loops would be required.
We are working around the input issues in several places. Fix the input, and you can remove the loops. Don't shoot the messenger.
If I may, I think a part of the problem is that previously we had some test modules, like desktop_runner and xterm that should be very simple and resilient and they "warm up" the system before more heavy tests are triggered. To me it seems that all is hitting the welcome test module now which in turn ends up complicated and unreliable. Not sure if we should change the order much but all least i it should be possible to run the desktop runner module first as it should not care about the screen section that is covered by the welcome dialog
Also available in: Atom
PDF