action #114730
closed
[Timebox: 16h] Investigate which job results block approval from qam-openqa review group
Added by geor almost 2 years ago.
Updated 9 months ago.
Description
Motivation¶
When a job from our aggregate maintenance updates fails, it blocks all the related maintenance updates from approval by the members of the qam-openqa group (maintenance openqa reviewers).
The questions arises, what job states, other than failed, result in maintenance updates being blocked?
Does for instance an incomplete job or a cancelled job also block their related updates?
Knowing this will help us better organize the required actions in the context of our Maintenance Update Review process.
Acceptance criteria¶
AC1 Figure out what job results block update approval for qam-openqa
Suggestions¶
The maintenance openqa reviewer use this dashboard http://dashboard.qam.suse.de/blocked to have visibility on the blocked updates.
The maintainer of this dashboard (maybe someone from qe-tools?) should be able to help.
Also we could check what happen when some arch doesn't run any job.
- Subject changed from [Timebox: 16h] Investigate what blocks approval from qam-openqa review group to [Timebox: 16h] Investigate which job results block approval from qam-openqa review group
I suppose if no specific fail on case, no block will happen on maintenance updates
I would suggest to modify AC2, because when fails in that way we don't have notification, and the only condition why we accept to do this daily review of MUs is that the notification system will help us, so we don't need to check the group if there is no notification, the agreement is that it would not be on-demand.
We could update the doc saying that 'if by chance we notice this' we can do A,B,C. wdyt?
Additional AC3 could reflect that we should file a ticket to tools teams to cover this enhancement in openQA notifications.
JERiveraMoya wrote:
I would suggest to modify AC2, because when fails in that way we don't have notification, and the only condition why we accept to do this daily review of MUs is that the notification system will help us, so we don't need to check the group if there is no notification, the agreement is that it would not be on-demand.
We could update the doc saying that 'if by chance we notice this' we can do A,B,C. wdyt?
Additional AC3 could reflect that we should file a ticket to tools teams to cover this enhancement in openQA notifications.
I agree with both your points, please edit the ticket freely to reflect those.
- Tags deleted (
qe-yast-refinement)
- Description updated (diff)
- Status changed from New to Workable
- Priority changed from Normal to Low
- Target version deleted (
Current)
- Status changed from Workable to New
- Status changed from New to Rejected
old ticket, we have solid procedures in YaM squad to avoid this blocking.
Also available in: Atom
PDF