action #104199
closed
QA - coordination #91646: [saga][epic] SUSE Maintenance QA workflows with fully automated testing, approval and release
Prevent confusion when openQA comments look like both a bugref as well as label at the same time size:M
Added by okurz almost 3 years ago.
Updated over 2 years ago.
Category:
Feature requests
Description
Motivation¶
See #95479#note-42 . If for example someone writes in an openQA comment label:force_result:passed:bsc#1234 then openQA does not detect this as a label but always as a bugref. So a bugref always wins over a label but this is not obvious to users
Acceptance criteria¶
- AC1: openQA guides the user to not create ambiguous "label + bugref" comments
- AC3: Any text starting with "label:" is not detected as an openQA bugref
Examples¶
- If user writes a comment with
bsc#1234 then this is parsed as bugref, expanded into a proper a href pointing to bugzilla.suse.com/…, openQA shows the bug icon and carries over the bug if jobs in the same scenario fail in the same way.
- user writes
label:force_result:softfailed:known_issue42 which changes the result of a job to "softfailed". openQA shows the "label" icon, no carry over happening
- User wants to create a comment with both a bugref and a label, e.g.
* module 1: bsc#1234
* module 2: label:ignore
- Desired behaviour, not currently working as expected: user wants to use a label and force the result of a single job (no carry over intended) but still wants to provide a proper link to a bug, e.g. again
bsc#1234 which would properly extended
- https://openqa.opensuse.org/tests/2118438#comments shows how multiple comments can include multiple bugrefs
Out of scope¶
Different visual representation of labels, see #104616
- Subject changed from Prevent confusion when openQA comments look like both a bugref as well as label at the same time to Prevent confusion when openQA comments look like both a bugref as well as label at the same time size:M
- Description updated (diff)
- Status changed from New to Workable
I've been thinking a bit about this and the obvious first solution to the problem would be to simply add something like label:\w+ to the already existing exclusion list ((?<![\(\[\"\>])) of prefixes that prevent bugref expansion. But having a list of disallowed prefixes is rather unintuitive for users. So i'd rather like to try a completely different approach first, which is to replace the exclusion list with the requirement that bugrefs need to be placed at the start of the line, or be preceded by whitespace.
kraih wrote:
So i'd rather like to try a completely different approach first, which is to replace the exclusion list with the requirement that bugrefs need to be placed at the start of the line, or be preceded by whitespace.
Do we have examples where that might not be the case? Off head I'd think the common case is simply the bugref on its own and nothing else. So that might effectively make not difference to current use cases.
cdywan wrote:
Do we have examples where that might not be the case? Off head I'd think the common case is simply the bugref on its own and nothing else. So that might effectively make not difference to current use cases.
There was actually a test case with two bugrefs separated by comma (which i've for now included as an alternative to whitespace prefix).
- Status changed from Workable to In Progress
- Due date set to 2022-01-22
Setting due date based on mean cycle time of SUSE QE Tools
For simplicity, i'd prefer not to implement AC2. The bugref regex we use for everything bugref related right now (multiple functions) is fairly complex, but has good test coverage. For AC2 we would need a second version of that regex, which is bound to lower coverage.
Maybe we can revisit AC2 after color highlighting of labels from #104616 has been implemented. That will certainly add more complexity to the situation and bring up new points to discuss.
ok, please extract AC2 into its own ticket, then continue
- Description updated (diff)
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
- Due date deleted (
2022-01-22)
Also available in: Atom
PDF