coordination #93246
Updated by okurz almost 3 years 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:** query parameters on /tests can be specified to show only jobs needing 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 * Distinguish between "plain comment", "label" and "bugref" same as we do in /tests/overview for the "todo"-parameter, don't care about the icons -> #94937 * 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, /tests as the feature should only be activated on explicit request by users * Displaying the different types of comments, see #94937 * 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