Project

General

Profile

action #119746

[spike][timeboxed:20h] Filter openQA todo-jobs on /tests belonging to one "review squad"

Added by okurz 3 months ago. Updated 16 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2022-11-02
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Motivation

Also see #118639. The idea is to be able to find openQA jobs that need review as they block approval of maintenance updates. To find jobs needing review we can already use the "todo" checkbox on /tests but we also need to filter out jobs in "development" or outside any job group as well as match on either the job group name, e.g. match "Core Maintenance" or match on not "Kernel Maintenance".

Suggestions

  • Proof of concept spike solution to filter jobs on /tests based on job group and job name. To be most flexible regex should be supported including also negative matches to exclude job names or job groups

Related issues

Related to openQA Project - action #117655: Provide API to get job results for a particular incident, similar to what dashboard/qem-bot does size:MResolved2022-10-06

History

#2 Updated by okurz 3 months ago

  • Related to action #117655: Provide API to get job results for a particular incident, similar to what dashboard/qem-bot does size:M added

#3 Updated by okurz 3 months ago

  • Status changed from New to Blocked
  • Assignee set to okurz

#117655 first

#4 Updated by okurz 3 months ago

  • Status changed from Blocked to New
  • Assignee deleted (okurz)
  • % Done changed from 30 to 0

#5 Updated by okurz 3 months ago

  • Target version changed from Ready to future

#6 Updated by mgrifalconi 2 months ago

Hello, we were thinking on something similar but on the dashboard.qam.suse.de since it feels the point of integration between openQA and SMELT. But any place is good, important is to fullfill the goal :)

As a reviewer (for my squad or openQA review task) I would like to see:

  • all failures related to a squad
  • ordered by how many release requests they are blocking (to help prioritize)
  • for how many runs (or days) they have been failing

From that view, we can also start collecting long term metrics, maybe with a CI in gitlab and feed into Grafana
Ideas of metrics:

  • failures/day
  • days before a failure is fixed
  • number of release requests blocked
  • morning vs evening failures (how much manual work was done to improve situation)

What do you think? How can we contribute?

#7 Updated by szarate 16 days ago

  • Parent task changed from #114929 to #118639

Changing the parent task to reflect the reality better

Also available in: Atom PDF