[qe-core][leap][sporadic] Fix chromium test failing due to dropped keys
The chromium test module fails sporadically because it is not resilient against dropped keys.
This particular failure happened because the
enter_cmd "chrome://version" line typed
chron instead of
openQA test in scenario opensuse-15.3-DVD-Updates-x86_64-gnome@64bit-2G fails in
- AC1: The test checks for incorrect input on the address bar using a needle that covers the expected input
- AC2: The test retries to input the adresses correctly N times (click the address bar and retype, better than using eg Ctrl-L in case the system is busy)
Fails since (at least) Build 20220217-3
Last good: 20220217-2 (or more recent)
Always latest result in this scenario: latest
failed already at https://openqa.opensuse.org/tests/2235822#step/updates_packagekit_gpk/24
I don't think this will work and stay stable for long time: 64bit-2G machine for such complete and updated installation, with testing of application like chromium.
I checked this and found in Jobgroup of DVD-Updates:
x86_64: opensuse-15.3-DVD-Updates-x86_64: - textmode: machine: 64bit - gnome: machine: uefi settings: QEMUVGA: cirrus - gnome: machine: 64bit-2G settings: QEMUVGA: cirrus
Same tests but on different machines and this is clearly a performance issue . 64bit-2G is so instable and won't schedule such heavy installation/update tests on it. I can exclude chromium for a observation. If other test modules are also love to fail, then I can un-schedule it.
- Status changed from In Progress to Rejected
https://openqa.opensuse.org/tests/2243321#next_previous no issue at all for chromium. 50 test runs, but there is other test module failed, vlc, oocalc.
So I would say, the performance issue of worker. but since I cannot reproduce this issue, there is no need to pay attention to it.
Set is for now as rejected. I can re-open it if chromium fails again.
- Status changed from Rejected to Blocked
Maybe this is related to an issue with call trace: https://bugzilla.opensuse.org/show_bug.cgi?id=1197122
So set is as blacked for now and wait feedback from developer.
according to my tests (more than 100 test runs), there is not a problem to chromium test module, but to performance of worker:
- no issue with qemuram, but found evidence for network issue: 10.162.30.85/tests/4923#step/updates_packagekit_gpl/17 and
- my assumption for poor cpu power, because there is no specific recording for cpu performance in logs, which cannot be determined at all.
- call trace has been displayed from POST_FAIL_HOOKS, not the problem causes failure Normal successful test run on my slow machine takes about 1 hour 50 minutes. So I don't see an issue with MAX_JOB_TIME=14400
okurz I would suggest to rapidly reduce the number of workers of 64G-2GB machine. Single worker on my test machine works fine and can prevent this kind of issue.
which worker host are you talking about here please? Yes, likely personal workstations have lower load anyway, so production tests need to accomodate for that within the test design.