action #93713
closedopenqa-in-OpenQA fails in openqa-from-containers
Description
Observation¶
Test in openqa-in-OpenQA fails in openqa-from-containers
See: https://openqa.opensuse.org/tests/1775715# and also several previous runs
# Test died: command 'for i in {1..3}; do docker build openQA/container/webui -t openqa_webui && break; done' timed out at openqa//tests/containers/build.pm line 8.
Updated by okurz almost 3 years ago
- Category set to Regressions/Crashes
- Status changed from New to Workable
- Priority changed from Normal to High
- Target version set to Ready
By default you can consider regressions in our tests as "Workable" and at least "High" and immediately in "Ready"
Updated by ilausuch almost 3 years ago
- Status changed from Workable to In Progress
- Assignee set to ilausuch
Updated by ilausuch almost 3 years ago
Well, the problem here is the time that this spend installing the packages during the building.
This could be a problem because of the weigth of the process (internal problem) or because the connectivity with the
repository mirrors (external problem).
I created this PR
https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/70
An alternative option could be to have a pre-built image with only the installation process.
I am thinking we could create a Dockerfile-base file with the installation, that will always be executed
previously, therefore when real Dockerfile will try to build will got this part from the previous image.
Updated by livdywan almost 3 years ago
ilausuch wrote:
Well, the problem here is the time that this spend installing the packages during the building.
This could be a problem because of the weigth of the process (internal problem) or because the connectivity with the
repository mirrors (external problem).I created this PR
https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/70
Okay, so this is bumping the timeout in case e.g. the worker is busy 🤔️
An alternative option could be to have a pre-built image with only the installation process.
I am thinking we could create a Dockerfile-base file with the installation, that will always be executed
previously, therefore when real Dockerfile will try to build will got this part from the previous image.
Can we publish and re-use the containers from compose.yml? That's already running for every PR.
Updated by ilausuch almost 3 years ago
It is not a reuse, because this could be dangerous and won't test this effectively. My point is to split the image in two. But after thinking in that, I don't believe it is a good solution:
- We don't have enough common installation process between the openQA containers (webui, worker,...)
- We will add confusion in the building process So I think we should discard this idea.
Updated by ilausuch almost 3 years ago
Merged. I'll wait some more test to check if this solution is really effective
Updated by openqa_review almost 3 years ago
- Due date set to 2021-06-30
Setting due date based on mean cycle time of SUSE QE Tools
Updated by ilausuch almost 3 years ago
- Status changed from In Progress to Resolved
Seems that the last runs went ok