action #43166
closed[functional][y] test fails in zypper_lifecycle_toolchain - expiration date of gcc7 changed , can we make the test more resilient?
0%
Description
****## Observation
openQA test in scenario sle-12-SP4-Server-DVD-s390x-gnome+proxy_SCC+allmodules@s390x-kvm-sle12 fails in
zypper_lifecycle_toolchain because gcc7 is being replaced by gcc8. Similar happened in #37695 . Can we make the test more resilient?
Reproducible¶
Fails since (at least) Build 0421
Expected result¶
Last good: 0421 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by okurz over 5 years ago
- Subject changed from test fails in zypper_lifecycle_toolchain - expiration date of gcc7 changed , can we make the test more resilient? to [functional][y] test fails in zypper_lifecycle_toolchain - expiration date of gcc7 changed , can we make the test more resilient?
- Assignee set to riafarov
@riafarov something for you as test module maintainer?
Updated by riafarov over 5 years ago
- Description updated (diff)
Again, my question will be either we make it strict and hence deal with required updates of the test or we can drop it because test accepts any date for any gcc package. Please, clarify that as per business values.
Updated by okurz over 5 years ago
The business value is in informing the customers about the specific expiration date. What we do on top is check the specific date and IMHO that is too much. We should just look for the packages to be mentioned explicitly and that's it.
Updated by riafarov over 5 years ago
Alright, I guess we are not much interested in this then. I will implement check that it's not expired and date is in future, and potentially check for any gcc version installed. However, I strongly believe that it significantly reduces value of the test module.
Updated by pcervinka over 5 years ago
I think that strict check by this test discovered not correctly update expirations in TCM.
If you fix expiration date according to recent TCM change, strict checking will show
http://10.100.12.105/tests/1162#step/zypper_lifecycle_toolchain/23 and I reported https://bugzilla.suse.com/show_bug.cgi?id=1114275.
Updated by okurz over 5 years ago
- Related to action #42527: [sle][migration][sle12sp4] test fails in zypper_lifecycle_toolchain - repository SLE-Module-Toolchain12-Updates not found added
Updated by pcervinka over 5 years ago
@okurz and @rwx788 yes, i would suggest to don't change current behavior as it helped to discover a bug. If there is an expiration change, it can be fixed by simple commit. Or configuration could be moved to variable to be more flexible.
Updated by riafarov over 5 years ago
- Status changed from New to Resolved
- Assignee changed from riafarov to pcervinka
Fixed by Petr: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6103#event-1939998609
https://openqa.suse.de/tests/2234475
As per discussion on github, we decided that as people are still interested in the strict check, we keep it as it is. Once it's not the case, we could lower the bar and accept something meaningful (e.g. any gcc version which expiration date is in future).