action #114730: [Timebox: 16h] Investigate which job results block approval from qam-openqa review group - qe-yam - openSUSE Project Management Tool

Actions

Copy link

action #114730

closed

[Timebox: 16h] Investigate which job results block approval from qam-openqa review group

Added by geor about 1 year ago. Updated 2 months ago.

Status:

Rejected

Priority:

Low

Assignee:

Target version:

Start date:

2022-07-27

Due date:

% Done:

Estimated time:

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.

Actions

Copy link

Updated by geor about 1 year ago

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

Actions

Copy link

Updated by coolgw about 1 year ago

I suppose if no specific fail on case, no block will happen on maintenance updates

Actions

Copy link

Updated by JERiveraMoya about 1 year ago

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.

Actions

Copy link

Updated by geor about 1 year ago

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.

Actions

Copy link