action #28198
closed
[sle][functional][medium] test fails in zypper_lifecycle - for repo in SLE-Products-SLES15-Pool"/> <solvable...
Added by SLindoMansilla over 6 years ago.
Updated over 6 years ago.
Category:
Bugs in existing tests
Description
Observation¶
The command was typed wrong. The output of the last command was used as input.
openQA test in scenario sle-15-Installer-DVD-x86_64-USBinstall@64bit fails in
zypper_lifecycle
Tasks¶
- Find out why it happens. (Max. 1h)
- Fix the test. (Max. 1h)
Reproducible¶
Fails since (at least) Build 346.1 (current job)
Expected result¶
Last good: 343.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
- Related to action #26112: [sle][functional] test fails in zypper_lifecycle - bash script fails added
- Related to action #16646: test fails in zypper_lifecycle to execute `curl...script` as the command is not typed completely added
- Status changed from New to Feedback
Sergio, we have to be a bit careful with job labelling. In https://openqa.suse.de/tests/1261782#comments I had labeled the job with a bug, you added the link to this progress ticket which is ok because you additionally saw that error. However in the next build as can be seen in https://openqa.suse.de/tests/1265138#comments only your comment was taken over as it was the last one. That gives the impression to the reader that the test only fails because of openQA issues and is hiding the bug. I think in such cases we should either not invest the effort to additionally label with test issues when there is already a valid product bug label or you take care to repeat the content from the previous comment in yours, e.g. like:
* most modules: bsc#1061051
* zypper_lifecyle: poo#28198
In this case I opt for the first option, don't care about the job if it's already labeled with a valid product bug.
- Status changed from Feedback to Resolved
Looks fine in last 2 builds, resolving.
I would have not labeled it if I saw it. And if I thought that the job was wrong labeled, I would remove the bug label to put the poo. So I assume that double labeling happened using openqa_label_all_tests_with_one_failing_modules. If we want to avoid this behavior, then we have to avoid using this script or update it.
Also available in: Atom
PDF