Project

General

Profile

Actions

action #108076

closed

[qe-core][15-sp4] test fails in libqt5_qtbase - Development tools module is not enabled

Added by punkioudi over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

The failure that appears is the following : Test died: 'zypper -n in libqt5-qttools yast2-installation' failed with code 104 (ZYPPER_EXIT_INF_CAP_NOT_FOUND)

This happens because the development tools is not enabled in this test.

Acceptance Criteria

  • AC1: Activate development-tools module in tests/x11/libqt5_qtbase.pm
  • AC2: Do the verification runs of the extra_tests_gnome_sdk in all the architectures (x86_64, ppc64le, aarch64. s390x) and make sure that the test passes.

Observation

openQA test in scenario sle-15-SP4-Online-x86_64-extra_tests_gnome_sdk@svirt-xen-pv fails in
libqt5_qtbase

Test suite description

Maintainer: jrauch. Extra tests about software in SDK module

Reproducible

Fails since (at least) Build 95.1

Expected result

Last good: 91.2 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by tjyrinki_suse over 2 years ago

  • Status changed from New to Workable
  • Target version set to QE-Core: Ready
  • Start date deleted (2022-03-09)
Actions #2

Updated by tjyrinki_suse over 2 years ago

  • Subject changed from [qe-core] test fails in libqt5_qtbase - Development tools module is not enabled to [qe-core][15-sp4] test fails in libqt5_qtbase - Development tools module is not enabled
  • Target version changed from QE-Core: Ready to QE-Core: Next
Actions #3

Updated by tjyrinki_suse over 2 years ago

  • Parent task set to #107323
Actions #4

Updated by tjyrinki_suse over 2 years ago

  • Target version changed from QE-Core: Next to QE-Core: Ready

Rationale:

  • bug in existing test not needing refining session
  • not in maintenance update, Normal priority is fine but current sprint needed since 15-SP4 is approaching
Actions #5

Updated by akumar over 2 years ago

  • Assignee set to akumar
Actions #7

Updated by akumar about 2 years ago

  • Status changed from Workable to In Progress
Actions #8

Updated by akumar about 2 years ago

I am noticing another issue in the recent runs of libqt5_qtbase test with needle matching - https://openqa.suse.de/tests/8450323#step/libqt5_qtbase/27
which I guess is due to - correct screen not being rendered before the needle matching. I tried adding a waiting time before the needle matching and had 5 successful runs. Creating a PR with the changes - https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/14657

Actions #10

Updated by akumar about 2 years ago

  • Status changed from In Progress to Resolved
Actions #11

Updated by openqa_review about 2 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: extra_tests_gnome_sdk
https://openqa.suse.de/tests/8635453#step/libqt5_qtbase/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions #12

Updated by punkioudi about 2 years ago

The reason of the aforementioned failing openqa test, is irrelevant of this progress ticket.

Actions #13

Updated by akumar about 2 years ago

Yes, the original issue of the ticket was to enable the development tools to be able to install libqt5-qttools package, which was resolved.
But I had also seen this needle mismatch failure during the verification runs of above fix and I had added another commit to include a wait time before the needle comparison, and that seemed to have worked fine. But now this failure is happening again so probably we need to tackle it as a new issue and a new progress ticket should be created.

Actions

Also available in: Atom PDF