Project

General

Profile

action #12110

gnome_control_center: short timeout on details caused test to fail

Added by sebchlad almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2016-05-24
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

observation

gnome_control_center fails as there is no details displayed as expected, e.g. see https://openqa.suse.de/tests/396384

problem

It seems like in staging we see issue with short timeout set to 3 so the the needle does not match to the expected results.

suggestions

  1. perhaps increase the timeout however that is a bad solution.

  2. should we monitor system resources to get the better picture instead of just increasing timeouts?


Related issues

Related to openQA Project - action #12064: Improved logging for debugging performance related issuesResolved2016-05-19

History

#1 Updated by okurz almost 6 years ago

  • Subject changed from gnome_control_center: short timeout on details caued test to fail to gnome_control_center: short timeout on details caused test to fail
  • Description updated (diff)
  1. sounds like a very good idea to me.

git grep 'assert_screen.*, [0-9];' yields still a whole lot of locations where we use assert_screen with a pretty low timeout, e.g. in x11 regression tests. We could set them all back to the default of 30 but I prefer to keep them and rather handle these failures accordingly. Interlinked to #12064

#2 Updated by okurz almost 6 years ago

  • Related to action #12064: Improved logging for debugging performance related issues added

#3 Updated by okurz almost 6 years ago

  • Description updated (diff)

#4 Updated by okurz almost 6 years ago

  • Status changed from New to In Progress

#5 Updated by okurz almost 6 years ago

  • Status changed from In Progress to Resolved

fixed with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1574

The idea in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1437 was deemed to be too complicated. The common understanding is: openQA is not really suitable for checking performance regressions by relying on hard timeouts. A better approach might be to read out the match times from the log files or add this data to some result files from which nice graphs could be rendered and such. For the issue at hand: Solved.

Also available in: Atom PDF