action #123106
closed
[tools][openQA-in-openQA][sporadic] test fails in docker build size:M
Added by jbaier_cz almost 2 years ago.
Updated almost 2 years ago.
Category:
Bugs in existing tests
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
- Related to action #119245: openQA in openQA test fails in docker build added
- Target version set to Ready
- Priority changed from Normal to Urgent
- Assignee set to jbaier_cz
- 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
- 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.
- Due date set to 2023-02-03
Setting due date based on mean cycle time of SUSE QE Tools
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).
- 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.
- Related to action #123496: [tools][openQA-in-openQA][sporadic] test fails in worker because of GNOME authentication dialog size:M added
Also available in: Atom
PDF