action #124316
[tools][openQA-in-openQA] test fails in openqa_worker auto_review:"zypper -n --gpg-auto-import-keys ref && zypper --no-cd -n in openQA-worker.*failed" size:M
0%
Description
Observation¶
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
openqa_worker
Problem: the to be installed openQA-worker-4.6.1676033243.8d9ce6f-5567.1.noarch requires 'openQA-common = 4.6.1676033243.8d9ce6f', but this requirement cannot be provided not installable providers: openQA-common-4.6.1676033243.8d9ce6f-5567.1.noarch[openQA] Solution 1: Following actions will be done: install openQA-common-4.6.1676033243.8d9ce6f-5567.1.noarch from vendor obs://build.opensuse.org/devel:openQA replacing openQA-common-4.6.1675863678.6b1808c-1.1.noarch from vendor openSUSE
The problem seems to be in the zypper repositories. Despite being clearly added and then successfully refreshed (video, 5 second mark), it seems that openQA-common is still pulled from the openSUSE repository instead during openQA-local-db
installation. (Note, that openQA-local-db is probably pulled from the openQA repo, see mark 0:12 in the video where openQA is version 4.6.1675863678 and openqa-local-db is 4.6.1676033243) This will create a conflict later in the setup when openQA-worker is about to install
Test suite description¶
Maintainer: okurz@suse.de Test for installation of openQA itself. To be used with "openqa" distri. Publishes an qcow2 image including the openQA installation ready to run as an appliance.
Reproducible¶
Fails since (at least) Build :TW.17756
Expected result¶
Last good: :TW.17755 (or more recent)
Further details¶
Always latest result in this scenario: latest
Suggestions¶
- Maybe we don't yet require the precise version in all our openQA sub-packages but should be.
- We should be able to ensure that we have consistent and updated repositories and then just trust proper priorities with
allow-vendor-change
. If we can't succeed in that then always explicitly install openQA from devel:: repos rather than Factory, e.g.--from-repo devel:openQA
. - If that also fails then check the OBS repository state before installing, e.g. similar as we already do in the trigger script https://github.com/os-autoinst/scripts/blob/master/trigger-openqa_in_openqa
Related issues
History
#1
Updated by jbaier_cz 4 months ago
- Related to action #123496: [tools][openQA-in-openQA][sporadic] test fails in worker because of GNOME authentication dialog size:M added
#5
Updated by cdywan 4 months ago
- Subject changed from [tools][openQA-in-openQA] test fails in openqa_worker auto_review:"command 'zypper -n --gpg-auto-import-keys ref && zypper --no-cd -n in openQA-.*failed" to [tools][openQA-in-openQA] test fails in openqa_worker auto_review:"command 'zypper -n --gpg-auto-import-keys ref && zypper --no-cd -n in openQA-.*failed" size:M
- Description updated (diff)
- Status changed from New to Workable
#6
Updated by jbaier_cz 4 months ago
As we are installing openQA-local-db in step one, we can begin with adding the version requirement to that: https://github.com/os-autoinst/openQA/pull/4997
#8
Updated by openqa_review 4 months ago
- Due date set to 2023-02-28
Setting due date based on mean cycle time of SUSE QE Tools
#9
Updated by jbaier_cz 4 months ago
- Subject changed from [tools][openQA-in-openQA] test fails in openqa_worker auto_review:"command 'zypper -n --gpg-auto-import-keys ref && zypper --no-cd -n in openQA-.*failed" size:M to [tools][openQA-in-openQA] test fails in openqa_worker auto_review:"zypper -n --gpg-auto-import-keys ref && zypper --no-cd -n in openQA-worker.*failed" size:M
#12
Updated by jbaier_cz 3 months ago
- Related to action #124497: [openQA-in-openQA] test fails in openqa_webui - "perl-Mojolicious-Plugin-Assetpack = 2.13" needed size:M added