Project

General

Profile

Actions

action #104199

closed

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.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-12-20
Due date:
% Done:

0%

Estimated time:

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


Related issues 1 (0 open1 closed)

Copied to openQA Project (public) - action #104616: Make openQA labels clearly visibleResolvedkraih2021-12-20

Actions
Actions #1

Updated by okurz almost 3 years ago

Actions #2

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)
Actions #3

Updated by okurz almost 3 years ago

  • Status changed from New to Workable
Actions #4

Updated by kraih almost 3 years ago

  • Assignee set to kraih
Actions #5

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.

Actions #6

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.

Actions #7

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).

Actions #9

Updated by kraih almost 3 years ago

  • Status changed from Workable to In Progress
Actions #10

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

Actions #11

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.

Actions #12

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.

Actions #13

Updated by okurz almost 3 years ago

ok, please extract AC2 into its own ticket, then continue

Actions #14

Updated by kraih almost 3 years ago

  • Description updated (diff)

Moved AC2 to #104778.

Actions #15

Updated by kraih almost 3 years ago

  • Status changed from In Progress to Feedback
Actions #16

Updated by kraih almost 3 years ago

  • Status changed from Feedback to Resolved
Actions #17

Updated by okurz over 2 years ago

  • Due date deleted (2022-01-22)
Actions

Also available in: Atom PDF