action #46502
closed
[tools] Support "record_info" in serial_failure_detection
Added by okurz almost 6 years ago.
Updated over 3 years ago.
Category:
Enhancement to existing tests
Description
Motivation¶
See https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6589#issuecomment-456419001 . As the serial failure detection supports only "soft" and "hard" now we can fail the job or use "soft" but for this we want to always have a bugref so probably we should support to just set an info popup without altering the test result.
Acceptance criteria¶
- AC1: serial issue detection can be used with a notice popup in test details but without altering the test result
- Related to action #45530: [aarch64] system_workarounds.pm triggers lib/known_bugs serial detection which abort whole test suite added
We don't want to paint it green
@szarate Not sure what you want to tell with your statement. Of course I am with you to not just mark "known bugs" by record_info instead of a soft-fail. Have you followed https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6589#issuecomment-456419001 and the whole discussion after that? The problem was with "noteworthy conditions" that can not have a workable bug behind where people also added record_soft_failure without bug references. Do you consider this feature worthwhile to follow up with or would you prefer an alternative?
- Subject changed from [functional][u] Support "record_info" in serial_failure_detection to [qe-core][functional] Support "record_info" in serial_failure_detection
- Assignee set to VANASTASIADIS
- Status changed from New to In Progress
VANASTASIADIS wrote:
In my understanding, what is being asked is to add a third type option - apart from the currently allowed soft and hard - and then in the backend where the actual parsing, regex matching and (soft)failing takes place, account for that third type using record_info to notify users and then proceeding without failing or softfailing.
Is that understanding correct?
that sounds like a good idea, yes.
Given that within the tools team we have a different focus for now and are exceeding our WIP limit I suggest you unassign again. Can you?
Apparently there was no comment here following my chat with Bill:
- There's the implementation in basetest.pm in os-autoinst which Bill would have to tackle from a Tools pov
- There's the distri part where the desired behavior can be implemented (qe-core)
- Why do we distinguish hardhard vs. softfail vs. "not a failure, not a bug" the point of that third, new option seems unclear
- We need a category that only provides more data for debugging even if by default it will not be used/needed
- Subject changed from [qe-core][functional] Support "record_info" in serial_failure_detection to [tools] Support "record_info" in serial_failure_detection
- Target version changed from future to Ready
Yes, I understand that now that this is related to os-autoinst. Then it's good. So we will take it over to the SUSE QE Tools team backlog.
- Due date set to 2021-05-21
Setting due date based on mean cycle time of SUSE QE Tools
- Status changed from In Progress to Resolved
Issue resolved.
Related pull requests:
Also available in: Atom
PDF