QA (public) » openQA Project (public) » openQA Tests (public)

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.

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

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.

agreed, the revert in #56789 fixed the more immediate problem.

needed another needle. Created, fixed: https://openqa.opensuse.org/tests/1079699