action #58574
closed[openqa] test fails in dashboard, desktop runner shows up a little bit late
0%
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
Updated by okurz about 5 years ago
- 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.
Updated by okurz about 5 years ago
- Related to action #56789: New needles from git repository not working with openqa-clone-custom-git-refspec added
Updated by okurz about 5 years ago
- 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
Updated by mkittler about 5 years ago
- Assignee deleted (
mkittler)
Like I said on IRC: Jobs which were executed while things were broken are not magically fixed afterwards. But https://openqa.opensuse.org/tests/1065621/modules/dashboard/steps/4/edit looks good again. I don't know what's wrong with the test itself but it doesn't look like an openQA issue anymore.
Updated by okurz about 5 years ago
- Assignee set to okurz
- Priority changed from Urgent to Normal
agreed, the revert in #56789 fixed the more immediate problem.
Updated by okurz about 5 years ago
- Status changed from Workable to Resolved
needed another needle. Created, fixed: https://openqa.opensuse.org/tests/1079699
Updated by okurz about 5 years ago
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