Project

General

Profile

Actions

action #110794

open

QA (public) - coordination #99303: [saga][epic] Future improvements for SUSE Maintenance QA workflows with fully automated testing, approval and release

Applying carry-over retroactively

Added by livdywan over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Motivation

https://openqa.suse.de/tests/8689982#next_previous shows several failures linked to #110671 - but 20 comments were retroactively added by hand. Maybe we can improve the workflow?

Suggestions

  • #110671 is a product issue which coveres several test modules
  • Automatic take-over won't apply retro-actively
  • label known issues could have been used by identifying and adding a regex to the ticket
  • openQA has no logic to relate the issues e.g. by finding the same error message in all jobs

Related issues 1 (0 open1 closed)

Related to openQA Project (public) - action #110881: Investigation jobs run because of the lack of automatic takeover size:SResolvedokurz2022-05-11

Actions
Actions #2

Updated by okurz over 2 years ago

  • Category set to Feature requests
  • Target version set to future
  • Parent task changed from #89062 to #99303

I consider the subject quite misleading. Because the automatic takeover does cover product issues just as well. It's just that there is no "retroactive carry-over" if that is what you are asking for

Actions #3

Updated by livdywan over 2 years ago

okurz wrote:

I consider the subject quite misleading. Because the automatic takeover does cover product issues just as well. It's just that there is no "retroactive carry-over" if that is what you are asking for

Does it? Takeover is always module-specific, isn't it? Please do correct the notes I took in the call this morning

Actions #4

Updated by okurz over 2 years ago

cdywan wrote:

okurz wrote:

I consider the subject quite misleading. Because the automatic takeover does cover product issues just as well. It's just that there is no "retroactive carry-over" if that is what you are asking for

Does it?

Does what? What do you refer to with "it"?

Takeover is always module-specific, isn't it?

Correct

Please do correct the notes I took in the call this morning

Sorry, I don't know how, yet, without understanding what you would like to see.

Actions #5

Updated by livdywan over 2 years ago

Please do correct the notes I took in the call this morning

Sorry, I don't know how, yet, without understanding what you would like to see.

The notes are not about what I want but what we discussed. I'm trying to identify something we can do to improve the situation based on the given user story. Unfortunately we closed the call without coming up with AC.

Actions #6

Updated by okurz over 2 years ago

  • Related to action #110881: Investigation jobs run because of the lack of automatic takeover size:S added
Actions #7

Updated by okurz over 2 years ago

  • Subject changed from Automatic takeover doesn't cover product issues to Applying carry-over retroactively

Might be related to #110881 . We started to discuss this ticket today and I think we can arrive at the conclusion after crosschecking carry-over behaviour that it works as expected. Maybe you meant to catch the idea of "Applying carry-over retroactively"

Actions

Also available in: Atom PDF