action #130150
closed[security] [15-SP4] test fails in seahorse_sshkey
0%
Description
Observation¶
This seems to have happened before in poo#128903 and handled in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17005/files.
openQA test in scenario sle-15-SP4-Server-DVD-Updates-x86_64-fips_env_mode_tests_crypt_x11@64bit fails in
seahorse_sshkey
Test suite description¶
Testsuite maintained at https://gitlab.suse.de/qe-security/osd-sle15-security.
Reproducible¶
Fails since (at least) Build 20230530-1
Expected result¶
Last good: 20230529-1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by emiler over 1 year ago
- Subject changed from test fails in seahorse_sshkey to [security] test fails in seahorse_sshkey
Updated by emiler over 1 year ago
- Related to action #128903: [security][15-SP4] fips_crypt_x11: test failed in seahorse_sshkey added
Updated by emiler over 1 year ago
- Subject changed from [security] test fails in seahorse_sshkey to [security] [15-SP4] test fails in seahorse_sshkey
Updated by FSzekely over 1 year ago
- Tags deleted (
fail)
I cannot reproduce the issue so far:
https://openqa.suse.de/tests/11384921
Updated by FSzekely over 1 year ago
Increased timeout from 3 to 6 seconds as openQA logs showed that 3 seconds was often too short.
https://openqa.suse.de/tests/11395926#step/seahorse_sshkey/26
The issue seems to be resolved. PR will follow.
Updated by FSzekely over 1 year ago
- Status changed from New to Resolved
Updated by emiler over 1 year ago
- Status changed from Resolved to Workable
Keeps happening in latest runs: https://openqa.suse.de/tests/11415277#step/seahorse_sshkey/28
Updated by FSzekely over 1 year ago
Updated by FSzekely over 1 year ago
Seems to be fine again lately:
https://openqa.suse.de/tests/11546415/modules/seahorse_sshkey/steps/1/src
Updated by emiler over 1 year ago
- Status changed from Workable to Resolved
Timeout increased from 6 to 8 seconds in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17469 for good measure. This should prevent any other timeout failures, so we can consider this stable.