action #155629
closedcoordination #99303: [saga][epic] Future improvements for SUSE Maintenance QA workflows with fully automated testing, approval and release
coordination #155671: [epic] Better handling of SLE maintenance test review
[spike][timeboxed:6h][qem-dashboard] Order blocked incidents by priority to allow reviewers to focus on higher prio incidents first size:S
0%
Description
Motivation¶
https://smelt.suse.de/overview/#testing shows incidents that are in testing with much more details about incidents than http://dashboard.qam.suse.de/blocked does. As apparently openQA test reviewers are not currently able to review all blocking test failures in time maintenance coordinators asked to better focus on incidents by priority. For this to select the higher prio incidents first the entries on http://dashboard.qam.suse.de/blocked should reflect the incident priority, e.g. order by priority or show the priority value.
Acceptance Criteria¶
- AC1: Proof-of-concept for ordering http://dashboard.qam.suse.de/blocked rows by incident priority
Suggestions¶
- Example of requesting incident priority for a single incident: https://smelt.suse.de/graphql/#query=%7B%0A%20%20incidents(incidentId%3A%2032579)%20%7B%0A%20%20%20%20edges%20%7B%0A%20%20%20%20%20%20node%20%7B%0A%20%20%20%20%20%20%20%20incidentpackagesSet%20%7B%0A%20%20%20%20%20%20%20%20%20%20edges%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20node%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20package%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20name%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20node%20%7B%0A%20%20%20%20%20%20%20%20priority%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D%0A
- Extend qem-bot and/or qem-dashboard as necessary to have incident priority available
- Lookup the most recent change handling embargoed updates ("embargoed" boolean value) for an example of how to add the new data from https://github.com/openSUSE/qem-dashboard/issues?q=is%3Aclosed+-label%3Adependencies+ and correspondingly from qem-bot (maybe https://github.com/openSUSE/qem-bot/pull/128 is relevant)
Updated by okurz 9 months ago
- Subject changed from [spike][timeboxed:4h] Incident priority on http://dashboard.qam.suse.de/blocked to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h] Incident priority on http://dashboard.qam.suse.de/blocked to allow reviewers to focus on higher prio incidents first
- Priority changed from Normal to High
- Target version changed from Tools - Next to Ready
Updated by okurz 9 months ago
- Subject changed from [spike][timeboxed:6h] Incident priority on http://dashboard.qam.suse.de/blocked to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first
Updated by okurz 9 months ago
- Subject changed from [spike][timeboxed:6h] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h][qem-dashboard] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first
- Description updated (diff)
Updated by livdywan 9 months ago
- Subject changed from [spike][timeboxed:6h][qem-dashboard] Order http://dashboard.qam.suse.de/blocked by incident priority to allow reviewers to focus on higher prio incidents first to [spike][timeboxed:6h][qem-dashboard] Order blocked incidents by priority to allow reviewers to focus on higher prio incidents first size:S
- Description updated (diff)
- Status changed from New to Workable
Updated by openqa_review 9 months ago
- Due date set to 2024-03-14
Setting due date based on mean cycle time of SUSE QE Tools
Updated by jbaier_cz 9 months ago · Edited
Could this caused the regression seen in https://gitlab.suse.de/qa-maintenance/bot-ng/-/jobs/2327744 ?
File "./qem-bot/bot-ng.py", line 7, in <module>
main()
File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/main.py", line 32, in main
sys.exit(cfg.func(cfg))
File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/args.py", line 34, in do_aggregate_schedule
bot = OpenQABot(args)
File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/openqabot.py", line 24, in __init__
self.incidents = get_incidents(self.token)
File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/loader/qem.py", line 41, in get_incidents
xs.append(Incident(i))
File "/builds/qa-maintenance/bot-ng/qem-bot/openqabot/types/incident.py", line 23, in __init__
self.priority = incident["priority"]
KeyError: 'priority'
Updated by jbaier_cz 9 months ago
- Related to action #156301: [bot-ng] Pipeline failed / KeyError: 'priority' / execution took longer than 4h0m0s seconds added
Updated by hrommel1 9 months ago
mkittler wrote in #note-11:
Handles in the other ticket.
So all PRs are prepared. If they are merged and deployed I'll have a look at whether it actually works. (Maybe there are still some bits missing.)
Does this change include the display of the priority from SMELT ?
From my experience it would be helpful to have this because it gives indications on if some updates have (almost) the same priority or if there are large gaps in the priority list.
Updated by mkittler 9 months ago
I'm not familiar with SMELT myself. Considering you're underlining "display" I assume there are multiple priorities. It is about the priority displayed on the top-right corner of pages like https://smelt.suse.de/incident/23314. In that example that would be 379 at the time I'm writing this comment. I'm not aware of any other priorities an incident might have.
If you are just referring to the word "important" left next to the figure: I think this is called "Rating". It will not be displayed anywhere at this point. I suppose it is computed from the prio. This computation could be done on the dashboard as well and shown somewhere on the "Blocked" page. I suppose that'll be another feature request. If we do this we need to make sure that SMELT and the dashboard agree on how the rating is computed. The SMELT API could also expose the computed value which the dashboard would just show as-is. This would ease keeping things in-line with each other but unless the SMELT API would also expose the background color the dashboard could not show the background color accordingly.
Updated by hrommel1 9 months ago
mkittler wrote in #note-13:
I'm not familiar with SMELT myself. Considering you're underlining "display" I assume there are multiple priorities. It is about the priority displayed on the top-right corner of pages like https://smelt.suse.de/incident/23314. In that example that would be 379 at the time I'm writing this comment. I'm not aware of any other priorities an incident might have.
Yes, that is exactly the priority value I mean.
It is displayed as well in the queue display of updates to be tested:
https://smelt.suse.de/overview/#testing (Column "Prio")
If you are just referring to the word "important" left next to the figure: I think this is called "Rating". It will not be displayed anywhere at this point. I suppose it is computed from the prio. This computation could be done on the dashboard as well and shown somewhere on the "Blocked" page. I suppose that'll be another feature request. If we do this we need to make sure that SMELT and the dashboard agree on how the rating is computed. The SMELT API could also expose the computed value which the dashboard would just show as-is. This would ease keeping things in-line with each other but unless the SMELT API would also expose the background color the dashboard could not show the background color accordingly.
The Rating should not be part of this implementation. Currently, we don't plan to have it displayed on https://dashboard.qam.suse.de/blocked
Updated by okurz 9 months ago
Waiting for second approval on https://github.com/openSUSE/qem-dashboard/pull/844
Updated by okurz 9 months ago · Edited
- Due date deleted (
2024-03-14) - Status changed from Feedback to Resolved
merged. http://dashboard.qam.suse.de/blocked now shows incident results ordered by priority and the individual incident results show additional information on the bottom. Now we just have to wait until somebody realizes that older low prio incidents are never reviewed which then no one would have expected :o
Updated by okurz 4 months ago
- Related to action #163586: [qem-dashboard] Display "consider manual approval" threshold on /blocked size:S added