[openqa] test fails in dashboard, desktop runner shows up a little bit late
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
Test suite description¶
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.
Fails since (at least) Build :TW.3227
Last good: :TW.3226 (or more recent)
Always latest result in this scenario: latest
#3 Updated by okurz about 2 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
#4 Updated by mkittler about 2 years ago
- Assignee deleted (
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.
#7 Updated by okurz about 2 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