action #58574

[openqa] test fails in dashboard, desktop runner shows up a little bit late

Added by okurz over 2 years ago. Updated over 2 years ago.

Bugs in existing tests
Target version:
Start date:
Due date:
% Done:


Estimated time:



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

Expected result

Last good: :TW.3226 (or more recent)

Further details

Always latest result in this scenario: latest

Related issues

Related to openQA Project - action #56789: New needles from git repository not working with openqa-clone-custom-git-refspecNew2019-09-11


#1 Updated by okurz over 2 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.

#2 Updated by okurz over 2 years ago

  • Related to action #56789: New needles from git repository not working with openqa-clone-custom-git-refspec added

#3 Updated by okurz over 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: 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: 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? looks for the desktop runner but gives up. Only the next screen 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 over 2 years ago

  • Assignee deleted (mkittler)

Like I said on IRC: Jobs which were executed while things were broken are not magically fixed afterwards. But looks good again. I don't know what's wrong with the test itself but it doesn't look like an openQA issue anymore.

#5 Updated by okurz over 2 years ago

  • Assignee set to okurz
  • Priority changed from Urgent to Normal

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

#6 Updated by okurz over 2 years ago

  • Status changed from Workable to Resolved

needed another needle. Created, fixed:

#7 Updated by okurz over 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 --parental-inheritance --skip-chained-deps 1083127 BUILD= _GROUP=0 CASEDIR=

Created job #1083431: openqa-Tumbleweed-dev-x86_64-Build:TW.3366-openqa_from_git@64bit-2G ->


Also available in: Atom PDF