action #93089
closed[qe-core][opensuse] Leap 15.3 test fails in zypper_extend
100%
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_REPOforget_required_var (QA_HEAD_REPO) - ensure the setting is set at the medium level
Updated by maritawerner almost 3 years ago
- Subject changed from Leap 15.3 test fails in zypper_extend to [qe-core] Leap 15.3 test fails in zypper_extend
Updated by tjyrinki_suse almost 3 years ago
- 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)
Updated by szarate almost 3 years ago
- Description updated (diff)
- Status changed from New to Workable
Updated by szarate almost 3 years ago
- Related to action #94853: [qe-core] new testruns added to leap 15.3 which are RED added
Updated by punkioudi almost 3 years ago
- % Done changed from 0 to 100
Added the fake mariadb package in [Leap15.3 project]
Added QA_HEAD_REPO=https://download.opensuse.org/repositories/devel:/openSUSE:/QA:/Leap:/15/openSUSE_Leap_15.3/ in the medium for Leap 15.3 Updates
Verification run : http://10.161.229.247/tests/2070#step/zypper_extend/189
Updated by punkioudi almost 3 years ago
- Status changed from Workable to Resolved
Updated by openqa_review almost 3 years ago
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
Updated by okurz almost 3 years ago
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
Updated by szarate almost 3 years ago
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.
Updated by okurz almost 3 years ago
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