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.
Category:
Bugs in existing tests
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
- 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 ?
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"
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.
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 :)
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.
- Status changed from Resolved to New
- Status changed from New to In Progress
- Status changed from In Progress to Resolved
- Target version set to QE-Core: Ready
Also available in: Atom
PDF