action #28198
closed[sle][functional][medium] test fails in zypper_lifecycle - for repo in SLE-Products-SLES15-Pool"/> <solvable...
0%
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
Updated by okurz over 6 years ago
- Related to action #26112: [sle][functional] test fails in zypper_lifecycle - bash script fails added
Updated by okurz over 6 years ago
- Related to action #16646: test fails in zypper_lifecycle to execute `curl...script` as the command is not typed completely added
Updated by riafarov over 6 years ago
This has to be resolved, it was wrong reg exp. And it worked fine in last run. So, I guess we can resolve it.
https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/eb5c8affbb0bbf2d79ead43190127c55b9b56bcc
Here is the run in the production:
https://openqa.suse.de/tests/1265136
Updated by okurz over 6 years ago
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.
Updated by riafarov over 6 years ago
- Status changed from Feedback to Resolved
Looks fine in last 2 builds, resolving.
Updated by SLindoMansilla over 6 years ago
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.