Project

General

Profile

Actions

action #124316

closed

[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

Added by jbaier_cz about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2023-02-11
Due date:
2023-02-28
% Done:

0%

Estimated time:

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 2 (0 open2 closed)

Related to openQA Tests - action #123496: [tools][openQA-in-openQA][sporadic] test fails in worker because of GNOME authentication dialog size:MResolvedosukup2023-01-232023-03-17

Actions
Related to openQA Project - action #124497: [openQA-in-openQA] test fails in openqa_webui - "perl-Mojolicious-Plugin-Assetpack = 2.13" needed size:MResolvedtinita2023-02-14

Actions
Actions #1

Updated by jbaier_cz about 1 year ago

  • Related to action #123496: [tools][openQA-in-openQA][sporadic] test fails in worker because of GNOME authentication dialog size:M added
Actions #2

Updated by jbaier_cz about 1 year ago

  • Subject changed from [tools][openQA-in-openQA][sporadic] test fails in openqa_worker to [tools][openQA-in-openQA] test fails in openqa_worker
Actions #3

Updated by mkittler about 1 year ago

  • Subject changed from [tools][openQA-in-openQA] test fails in openqa_worker 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"
Actions #4

Updated by jbaier_cz about 1 year ago

  • Description updated (diff)
  • Assignee set to jbaier_cz
Actions #5

Updated by livdywan about 1 year 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
Actions #6

Updated by jbaier_cz about 1 year 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

Actions #7

Updated by jbaier_cz about 1 year ago

  • Status changed from Workable to In Progress
Actions #8

Updated by openqa_review about 1 year ago

  • Due date set to 2023-02-28

Setting due date based on mean cycle time of SUSE QE Tools

Actions #9

Updated by jbaier_cz about 1 year 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
Actions #11

Updated by livdywan about 1 year ago

  • Status changed from In Progress to Feedback

okurz wrote:

https://github.com/os-autoinst/openQA/pull/4997 merged

Seems like it might be fine? But let's wait, since we do have some failures in the same test distri currently.

Actions #12

Updated by jbaier_cz about 1 year ago

  • Related to action #124497: [openQA-in-openQA] test fails in openqa_webui - "perl-Mojolicious-Plugin-Assetpack = 2.13" needed size:M added
Actions #13

Updated by livdywan about 1 year ago

  • Status changed from Feedback to Resolved

Let's assume openqa-label-known-issues would catch this since it has an expression in the subject, so we can close and it'll re-open if needed

Actions

Also available in: Atom PDF