action #124316
Updated by livdywan about 1 year ago
## Observation openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in [openqa_worker](https://openqa.opensuse.org/tests/3111266/modules/openqa_worker/steps/3) ``` 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](https://openqa.opensuse.org/tests/3111266#step/openqa_webui/7) 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](https://openqa.opensuse.org/tests/3110448) ## Expected result Last good: [:TW.17755](https://openqa.opensuse.org/tests/3110445) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=openqa&flavor=dev&machine=64bit-2G&test=openqa_install%2Bpublish&version=Tumbleweed) ## 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