action #44708
closed
[sle][functional][y] test fails in enable_usb_repo - Unschedule enable_usb_repo
Added by JERiveraMoya over 5 years ago.
Updated over 5 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 21
- Due date set to 2018-12-18
- Priority changed from Normal to High
- Target version set to Milestone 21
We should clarify why this starts to fail now.
- Status changed from New to Workable
- Priority changed from High to Urgent
I somehow expected that we will use that INSTALLATION_VALIDATION variable to enable it, but yeah, let's fix the regressions we have introduced! ;)
- Related to action #42917: [sle][functional][y] Introduce only relevant tests modules for USBinstall test suite added
- Status changed from Workable to Rejected
- Assignee set to okurz
let's reopen #42917 as it is a direct regression and the other ticket has more information
- Status changed from Rejected to In Progress
- Status changed from In Progress to Workable
- Assignee deleted (
okurz)
- Priority changed from Urgent to Normal
- Priority changed from Normal to Urgent
- Estimated time set to 3.00 h
EXCLUDE_MODULES variable can be set to reduce priority.
- Priority changed from Urgent to Normal
Other hints: Just evaluate the schedule locally with e.g. isotovideo -d _exit_after_schedule=1 or run clones on production, e.g. clone from o3 to o3.
Ping - this still impacts Leap 15.0, 15.1 and TW.
Why was the regression introducing commit not simply reverted until a proper one is available?
It is a regression in the sense that make red the test, but in fact it is not. This test does not make sense to schedule it here, it was doing nothing (enabling a repo that was already enabled and that was not even usb), so therefore we have schedule to work on this test during this sprint as we don't have easy way to unschedule tests (due to main.pm problem we all are aware) without minimal testing/cloning. Besides that the original PR is correct and fix it for sle15sp1 in a test suite where the test module should be scheduled.
- Status changed from Workable to In Progress
- Assignee deleted (
riafarov)
- Status changed from In Progress to Workable
- Assignee set to riafarov
- Status changed from Workable to Feedback
JERiveraMoya wrote:
[…] as we don't have easy way to unschedule tests (due to main.pm problem we all are aware)
I think using EXCLUDE_MODULES would be an easy way just as well as excluding the single test module within the main.pm file is. Let's use this as an example for next time to know that actually people care about the test results more than than we might think ;)
I was not aware of this feature before. Potential issue that I see is (1) that prevent us to create better solution analyzing other tests suites affected and (2) is easy to "hide" your test failing as result of your PR and there is not trace of that (a progress ticket to discuss about unscheduling it). The reviewer can make a bad decision and makes it more difficult for following reviews as for example remove a test could potentially also affect following tests in a testsuite so comparing test suite is even more tricky. I guess is risky to use it but if properly discuss in the channel during review can help while we find better solution for main.pm.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF