action #43229

Could openQA automatic takeover more than 1 known bsc/poo

Added by yosun over 1 year ago. Updated 9 months ago.

Status:RejectedStart date:01/11/2018
Priority:NormalDue date:
Assignee:okurz% Done:

0%

Category:Feature requests
Target version:Done
Difficulty:
Duration:

Description

The most useful feature for test reviewer in openQA is automatic takeover 1 bug from previous run.
I have a test contain 6 bugs and 1 poo, but every time openqa automatic takeover 1 bug from previous builds. Could openqa automatic takeover them all?

e.g. https://openqa.suse.de/tests/2231251#comments

History

#1 Updated by rpalethorpe over 1 year ago

I will implement this in JDP instead of OpenQA (it could still be implemented in OpenQA as well).

#2 Updated by nicksinger over 1 year ago

  • Project changed from openQA Infrastructure to openQA Project
  • Category set to Feature requests

#3 Updated by mitiao about 1 year ago

Looks easy to takeover all bsc/poo, just curious to know any concern to only takeover 1 bsc/poo in current code?

#4 Updated by coolo about 1 year ago

  • Target version set to Ready

I'm fine with taking over the latest comment containing one or multiple issues. I'm against merging issue comments or taking over multiple comments.

#5 Updated by yosun about 1 year ago

Yeah, no need to takeover comments, but issues/poo are really needed :)

#6 Updated by okurz about 1 year ago

@yosun I am not quite sure if you understood coolo. Every "bug reference" within openQA is also a comment.

Taking over multiple issues is easy and already working: Just do what we already do for very long e.g. within the openSUSE tests, write one comment with a list of references. Take for example https://openqa.opensuse.org/tests/813745#comment-31402 using a proper markdown list with the module and the according ticket reference.

I assume extending the comments on job level to reference multiple issues in multiple failing modules and trying to carry that over to another job with multiple issues in potentially different failing modules would be very complicated and error-prone. I would rather suggest to invest the effort into a different approach to better identify "known failures" and track these not in job comments, e.g. see #39719

#7 Updated by mkittler about 1 year ago

I'm fine with taking over the latest comment containing one or multiple issues.

And that already seems to work (see Oliver's example: https://openqa.opensuse.org/tests/813745#comment-31402). So can we consider the issue resolved/rejected then?

#8 Updated by okurz about 1 year ago

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

Let's assume yes, anyone can reopen with a clear different expectation of course

#9 Updated by yosun about 1 year ago

@okurz Thanks to notice, I did misunderstood coolo.
But that markdown solution in one comment works for me, what I need it's a solution. Thanks.

#10 Updated by coolo about 1 year ago

  • Category changed from Feature requests to 140

@mitiao I suggest you take the opportunity and document these ways

#11 Updated by coolo 9 months ago

  • Target version changed from Ready to Done

Also available in: Atom PDF