Project

General

Profile

Actions

action #93186

closed

[qem][maint][zypper_lifecycle_toolchain]test fails in zypper_lifecycle_toolchain

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

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

100%

Estimated time:
Difficulty:

Description

Jozef is looking into it.

Observation

openQA test in scenario sle-12-SP3-Server-DVD-Updates-x86_64-qam-allpatterns+addons@64bit fails in
zypper_lifecycle_toolchain

Test suite description

All modules defined in SCC_ADDONS
#20201124: added chrony-pool-openSUSE due to 15SP1 QU5 failure https://openqa.suse.de/tests/5060854

Reproducible

Fails since (at least) Build 20210526-1

Expected result

Last good: 20210525-1 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by okurz over 2 years ago

dzedro has a minor fix in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12860

Why do we even need to hardcode dates which need a manual update of the test code from time to time?
The original test module was introduced in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3053
with commit bc47c07e5 referencing fate#322050 and #15306
How about searching for any version of gcc and checking that at least one gcc is not expired without hardcoding a date?

Actions #2

Updated by dzedro over 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

zypper_lifecycle_toolchain is most useless test, it's nice to have it right, but I think nobody cares about this dates or at least the attention and work it already needed is just annoying.
Wop wop lifecycle date of gcc is (kind of) correct!
Yes not hardcoding the date is the solution, what will be the source of this information ?

Actions #3

Updated by okurz over 2 years ago

dzedro wrote:

zypper_lifecycle_toolchain is most useless test, it's nice to have it right, but I think nobody cares about this dates or at least the attention and work it already needed is just annoying.
Wop wop lifecycle date of gcc is (kind of) correct!

Why not just delete it then?

Yes not hardcoding the date is the solution, what will be the source of this information ?

You don't need the exact date as long as it has not yet expired, e.g.

  • check that gcc5 has expired, i.e. expiration "Now" (already implemented)
  • zypper se gcc to find current versions, read out latest, check that expiration is "!Now"
Actions #4

Updated by dzedro over 2 years ago

okurz wrote:

dzedro wrote:

zypper_lifecycle_toolchain is most useless test, it's nice to have it right, but I think nobody cares about this dates or at least the attention and work it already needed is just annoying.
Wop wop lifecycle date of gcc is (kind of) correct!

Why not just delete it then?

That would be so great and easy.

Yes not hardcoding the date is the solution, what will be the source of this information ?

You don't need the exact date as long as it has not yet expired, e.g.

  • check that gcc5 has expired, i.e. expiration "Now" (already implemented)
  • zypper se gcc to find current versions, read out latest, check that expiration is "!Now"

I will try to prepare some change to check the expiration differently.

Actions #5

Updated by okurz over 2 years ago

dzedro wrote:

okurz wrote:

dzedro wrote:

zypper_lifecycle_toolchain is most useless test, it's nice to have it right, but I think nobody cares about this dates or at least the attention and work it already needed is just annoying.
Wop wop lifecycle date of gcc is (kind of) correct!

Why not just delete it then?

That would be so great and easy.

but I mean it! We still have the "zypper_lifecycle" test module. I would have suggested a PR already to delete the test module but as you mentioned that you would look into checking the expiration differently I leave that to you. Or ping me and I will propose the deletion PR :)

Actions #6

Updated by dzedro over 2 years ago

okurz wrote:

dzedro wrote:

okurz wrote:

dzedro wrote:

zypper_lifecycle_toolchain is most useless test, it's nice to have it right, but I think nobody cares about this dates or at least the attention and work it already needed is just annoying.
Wop wop lifecycle date of gcc is (kind of) correct!

Why not just delete it then?

That would be so great and easy.

but I mean it! We still have the "zypper_lifecycle" test module. I would have suggested a PR already to delete the test module but as you mentioned that you would look into checking the expiration differently I leave that to you. Or ping me and I will propose the deletion PR :)

Yes, but zypper_lifecycle is checking different product. I will either "fix" or delete it.

Actions #7

Updated by dzedro over 2 years ago

  • Status changed from Resolved to New
Actions #8

Updated by dzedro over 2 years ago

  • Status changed from New to In Progress
Actions #9

Updated by dzedro over 2 years ago

  • Status changed from In Progress to Resolved
Actions #10

Updated by szarate over 2 years ago

  • Target version set to QE-Core: Ready
Actions

Also available in: Atom PDF