action #93089
closed
[qe-core][opensuse] Leap 15.3 test fails in zypper_extend
Added by lkocman almost 3 years ago.
Updated over 2 years ago.
Category:
Bugs in existing tests
Description
Observation¶
Zypper seems to fail as he expects a repo file on input and that doesn't seem to be the case in test.
This is due to missing QA_HEAD_REPO in the job settings (but why?)
2021-05-25 02:40:54 susetest(18652) [zypper] add.cc(execute):94 Not a repo file.
2021-05-25 02:40:54 susetest(18652) [zypper] Zypper.h(setExitCode):164 setExitCode 3
Reproducible¶
Fails since (at least) Build 32.4
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Suggestions¶
- modify the
get_var QA_HEAD_REPO for get_required_var (QA_HEAD_REPO)
- ensure the setting is set at the medium level
- Subject changed from Leap 15.3 test fails in zypper_extend to [qe-core] Leap 15.3 test fails in zypper_extend
- Subject changed from [qe-core] Leap 15.3 test fails in zypper_extend to [qe-core][opensuse] Leap 15.3 test fails in zypper_extend
- Start date deleted (
2021-05-25)
- Description updated (diff)
- Status changed from New to Workable
- Assignee set to punkioudi
- Related to action #94853: [qe-core] new testruns added to leap 15.3 which are RED added
- % Done changed from 0 to 100
- Status changed from Workable to Resolved
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: extra_tests_textmode
https://openqa.opensuse.org/tests/1757089
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The label in the openQA scenario is removed
hm, https://openqa.opensuse.org/tests/1757089 is still the last build of Leap 15.3 from 2 months ago. Maybe you can try if a new run of the failing scenario will show the fix working? As alternatives try to help bring 15.4 tests into action so that these would be considered the "latest" test results. As another alternative move the job group "Leap 15" into "Released" until it will be reused for 15.4 tests again
okurz wrote:
hm, https://openqa.opensuse.org/tests/1757089 is still the last build of Leap 15.3 from 2 months ago. Maybe you can try if a new run of the failing scenario will show the fix working? As alternatives try to help bring 15.4 tests into action so that these would be considered the "latest" test results. As another alternative move the job group "Leap 15" into "Released" until it will be reused for 15.4 tests again
I think your script needs either a "memory" or a different fix to "Not look at jobs that haven't ran for more than a month"
In the long run, neither of your suggestions nor the bot's are useful, if we stick to keeping a single job group for development.
szarate wrote:
okurz wrote:
hm, https://openqa.opensuse.org/tests/1757089 is still the last build of Leap 15.3 from 2 months ago. Maybe you can try if a new run of the failing scenario will show the fix working? As alternatives try to help bring 15.4 tests into action so that these would be considered the "latest" test results. As another alternative move the job group "Leap 15" into "Released" until it will be reused for 15.4 tests again
I think your script needs either a "memory" or a different fix to "Not look at jobs that haven't ran for more than a month"
The script is github.com/os-autoinst/openqa_review.
Well, so far the "memory" is kept in openQA and the issue trackers themselves as openqa-review looks at the date of the tests as well as the date of the last comment in an issue. I guess it would be possible to ignore test results which are "older than X"
In the long run, neither of your suggestions nor the bot's are useful, if we stick to keeping a single job group for development.
You mean the single job group for Leap regardless of the version? A separate job group has multiple disadvantages. Also, this was not a problem in the past
- Target version set to QE-Core: Ready
Also available in: Atom
PDF