action #123106
closed[tools][openQA-in-openQA][sporadic] test fails in docker build size:M
0%
Description
Observation¶
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_from_containers@64bit-2G fails in
build
The docker build fails during zypper installation, package openQA-common not found on medium (can be seen on video on mark 4:00). Likely issues with the repository (or its mirror).
Test suite description¶
Maintainer: okurz@suse.de Test for running openQA itself from containers. To be used with "openqa" distri. Introduced retry on the job level due to https://progress.opensuse.org/issues/108665 as there can still be sporadic network issues sometimes.
Reproducible¶
Fails since (at least) Build :TW.15047
Expected result¶
Last good: :TW.15046 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by jbaier_cz almost 2 years ago
- Related to action #119245: openQA in openQA test fails in docker build added
Updated by mkittler almost 2 years ago
- Subject changed from [tools][openQA-in-openQA][sporadic] test fails in docker build to [tools][openQA-in-openQA][sporadic] test fails in docker build size:M
- Status changed from New to Workable
Updated by jbaier_cz almost 2 years ago
- Status changed from Workable to In Progress
The failure we see is still during the docker build, i.e. within the Dockerfile. It seems to me, that it is not desirable nor correct to complicate the Dockerfile with the retry logic. So I will try solve that on the test level. Maybe I would be able to parse the docker output and rerun for zypper issues or at least record_info with this progress ticket for some automatic processing.
Updated by openqa_review almost 2 years ago
- Due date set to 2023-02-03
Setting due date based on mean cycle time of SUSE QE Tools
Updated by jbaier_cz almost 2 years ago
Known error during zypper operation is recognized and recorded: https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/106
Maybe we can then use auto-review to handle and label the failure?
Updated by livdywan almost 2 years ago
jbaier_cz wrote:
Known error during zypper operation is recognized and recorded: https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/106
We brainstormed some ideas for a follow-up in case both extending the timeout and the number of attempts aren't good enough. 1) OBS never builds with internet connectivity, and the only reliable option would be to avoid that here as well. 2) Ultimately the test fails on a missing external dependency, maybe we could handle that after the job fails if we can reliably detect it.
For now we probably want to increase the number of attemps since we already get exponential back-off's (commente don the PR).
Updated by okurz almost 2 years ago
Updated by jbaier_cz almost 2 years ago
- Due date deleted (
2023-02-03) - Status changed from In Progress to Resolved
The code with more attempts is online, we will see if that helped eventually.
Updated by jbaier_cz almost 2 years ago
- Related to action #123496: [tools][openQA-in-openQA][sporadic] test fails in worker because of GNOME authentication dialog size:M added