Project

General

Profile

Actions

action #108114

closed

[qe-core] test fails in addon_products_sle

Added by zluo almost 3 years ago. Updated over 2 years ago.

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

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-15-SP3-Online-QR-SLED-x86_64-gnome@uefi fails in
addon_products_sle

Test suite description

Testsuite maintained at https://gitlab.suse.de/qa-maintenance/qam-openqa-yml. Maintainer: slindomansilla

The standard scenario where we mainly just follow installation suggestions without any adjustments as long as the default desktop is gnome.

Reproducible

Fails since (at least) Build 200.13

Expected result

Last good: 200.10 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by zluo almost 3 years ago

  • Start date deleted (2022-03-10)
Actions #2

Updated by tjyrinki_suse almost 3 years ago

  • Subject changed from [qa-core] test fails in addon_products_sle to [qe-core] test fails in addon_products_sle
  • Status changed from New to Workable
  • Parent task set to #107968

New problem in QR.

It seems like a product change that now there is a High Availability license agreement that there wasn't before.

Actions #3

Updated by dzedro almost 3 years ago

tjyrinki_suse wrote:

New problem in QR.

It seems like a product change that now there is a High Availability license agreement that there wasn't before.

This is happening when the license is different [1][2] than https://openqa.suse.de/tests/8307161#step/accept_license/3
I guess this should not happen, no idea why is it happening now or why is the license different.

[1] https://github.com/yast/yast-packager/pull/356
[2] https://github.com/yast/yast-packager/pull/282

Actions #4

Updated by LMartin almost 3 years ago

dzedro wrote:

tjyrinki_suse wrote:

New problem in QR.

It seems like a product change that now there is a High Availability license agreement that there wasn't before.

This is happening when the license is different [1] than https://openqa.suse.de/tests/8307161#step/accept_license/3
I guess this should not happen, no idea why is it happening now or why is the license different.

Agree, I also think this should not be happening.
Can we open a bug for this please.

[1] https://github.com/yast/yast-packager/pull/356

@tjyrinki_suse
Cool you guys found this, thanks. How come your are testing HA modules? This is really good, just unexpected.

Actions #5

Updated by lpalovsky almost 3 years ago

LMartin wrote:

Can we open a bug for this please.

Bug opened:
https://bugzilla.suse.com/show_bug.cgi?id=1197184

Actions #6

Updated by tjyrinki_suse almost 3 years ago

Thanks for filing the bug too!

@tjyrinki_suse
Cool you guys found this, thanks. How come your are testing HA modules? This is really good, just unexpected.

Not sure why in SLES test we select the HA module too, but indeed it doesn't hurt either.

Actions #7

Updated by dheidler over 2 years ago

It this progress issue here still needed as we have the bug to track it?

Actions #8

Updated by tjyrinki_suse over 2 years ago

  • Status changed from Workable to Resolved
  • Assignee set to tjyrinki_suse
  • Priority changed from Normal to High

This ticket in itself is no longer needed, the final conclusion yesterday was that it is a product bug that needs to be fixed, there's nothing to change in the tests.

Actions

Also available in: Atom PDF