action #58574
closed
[openqa] test fails in dashboard, desktop runner shows up a little bit late
Added by okurz about 5 years ago.
Updated about 5 years ago.
Category:
Bugs in existing tests
Description
Observation¶
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
dashboard
Test suite description¶
Maintainer: okurz@suse.de
Test for installation of openQA itself. To be used with "openqa" distri.
Publishes an qcow2 image including the openQA installation ready to run as an appliance.
Reproducible¶
Fails since (at least) Build :TW.3227
Expected result¶
Last good: :TW.3226 (or more recent)
Further details¶
Always latest result in this scenario: latest
Related issues
1 (1 open — 0 closed)
- Status changed from New to Blocked
- Assignee set to okurz
working on openqa-in-openqa tests already, e.g. #57014 , let's see if I can cover this as well after having finished the first parts first.
- Related to action #56789: New needles from git repository not working with openqa-clone-custom-git-refspec added
- Status changed from Blocked to Workable
- Assignee changed from okurz to mkittler
- Priority changed from Normal to Urgent
We have another problem, very likely to be related to your changes: https://openqa.opensuse.org/tests/1065566/modules/dashboard/steps/2/edit shows "Could not parse needle: desktop-runner-20180410 for openqa Tumbleweed" and the openQA-in-openQA tests do not find any needle. Should we hope this is fixed with your recent PR?
EDIT: https://openqa.opensuse.org/tests/1065578#step/dashboard/2 seems to be back to the "old problem", the desktop runner needle could be correctly loaded but it is not found (in time). It seems there is also a regression in product behaviour.
[25/10/2019 15:13:27] <okurz> DimStar: btw, could it be there is a performance regression in the gnome desktop runner since some builds? https://openqa.opensuse.org/tests/1065578#step/dashboard/2 looks for the desktop runner but gives up. Only the next screen https://openqa.opensuse.org/tests/1065578#step/dashboard/3 shows it
[25/10/2019 15:17:22] <DimStar> okurz: hm.. it's not impossible - 'a couple builds' ago could have been gnome 3.34 update?
[25/10/2019 15:17:38] <DimStar> (was 1017)
[25/10/2019 15:18:14] <okurz> yes, sounds like it. How realistic would it be to report a bug and wait for its fix? zero?
[25/10/2019 15:19:27] <DimStar> okurz: I'd say at least close to zero. on my not-so-new-machine pressing alt-f2 shows up the runner almost instantly
- Assignee deleted (
mkittler)
- Assignee set to okurz
- Priority changed from Urgent to Normal
agreed, the revert in #56789 fixed the more immediate problem.
- Status changed from Workable to Resolved
Actually I think I never fixed the original problem properly. check_screen sometimes fails to detect the desktop runner as there is a 0 second timeout. Trying to use a multi-tag assert_screen:
openqa-clone-job --within-instance https://openqa.opensuse.org --parental-inheritance --skip-chained-deps 1083127 BUILD= _GROUP=0 CASEDIR=https://github.com/okurz/os-autoinst-distri-openQA.git#fix/runner
Created job #1083431: openqa-Tumbleweed-dev-x86_64-Build:TW.3366-openqa_from_git@64bit-2G -> https://openqa.opensuse.org/t1083431
-> https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/51
Also available in: Atom
PDF