action #104199
closedQA (public) - 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
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#1234then this is parsed as bugref, expanded into a propera hrefpointing 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_issue42which 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#1234which 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
Updated by okurz almost 3 years ago
- Copied to action #104616: Make openQA labels clearly visible added
Updated by okurz almost 3 years ago
- 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)
Updated by kraih almost 3 years ago
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.
Updated by livdywan almost 3 years ago
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.
Updated by kraih almost 3 years ago
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).
Updated by kraih almost 3 years ago
Possible solution. https://github.com/os-autoinst/openQA/pull/4437
Updated by openqa_review almost 3 years ago
- Due date set to 2022-01-22
Setting due date based on mean cycle time of SUSE QE Tools
Updated by kraih almost 3 years ago
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.
Updated by kraih almost 3 years ago
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.
Updated by okurz almost 3 years ago
ok, please extract AC2 into its own ticket, then continue
Updated by kraih almost 3 years ago
- Status changed from In Progress to Feedback