Project

General

Profile

action #93246

Updated by okurz 3 months ago

## Motivation
As a test reviewer and member of one of many QA squads I want to find unreviewed openQA test failures on /tests to have access to a single page showing all failures needing review work.

Also see parent #89062

## Acceptance criteria
* **AC1:** A query parameter "todo=1" parameters on /tests can be specified to show only jobs needing review, same as we do on /tests/overview a label, e.g. "failed/incomplete/timeout_exceeded" with no "label" nor "bugref"

## Suggestions
/tests can already be configured like https://openqa.opensuse.org/tests/?resultfilter=Failed&resultfilter=Incomplete&resultfilter=timeout_exceeded , even over UI elements. Also /tests already shows a comments icon but makes no distinction like on /tests/overview or "next & previous" between "plain comment", "label" or "bugref".

* Try t/ui/01-list.t and see if you can extend it
* Add query parameter to filter only jobs that need review, e.g. "todo=1", same as on /tests/overview . At best use the same logic to prevent duplication


* Optional: Add UI element to configure this, e.g. again like on /tests/overview the "todo" checkbox
* Optional: Add further filter query parameters (+doc, +UI control elements) for
* job group include/exclude regex (similar to what we have on the index page)
* filter for "no group/any group"
* test module include/exclude regex
* further filter possibilities, e.g. medium, flavor, arch, machine

## Further details

We already provide an IRC bridge that notifies about all unreviewed test failures (see https://github.com/openSUSE/suse_msg/blob/master/suse_msg/meta/openqa.py#L23 and https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Plugin/AMQP.pm#L109 ).

##
Out of scope
* Don't care about the "running" or "scheduled" jobs on /tests as long as they at least show something useful when no manual query parameters are used or no filtering box selection has been made.
* Performance improvements on /tests, as the feature should only be activated on explicit request by users
* Don't care about the number of jobs that are displayed after all the filters apply. https://openqa.opensuse.org/tests?match=toolkits&resultfilter=Failed is one example showing that there can be enough "review candidates" depending on the specified test suite
* Don't care about changing the limit of jobs (e.g. more than 500)
* Don't care about filtering the job for other parameters like job group, scenario name, result, state, etc.

Back