action #12092

[tools][dashboard][Feature] - make openQA show when a bug is marked as "RESOLVED FIXED" but still in the product

Added by dgutu almost 4 years ago. Updated almost 2 years ago.

Status:ResolvedStart date:18/11/2017
Priority:HighDue date:
Assignee:dheidler% Done:

100%

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

Description

Idea came on to Richard on openQA hackaton:
Make openQA show when a bug is marked as "RESOLVED FIXED" but still in the product

Acceptance Criteria

  • The Bug icons on the test result matrix page should indicate the status (open/closed) of the bug

Optional:

  • More detailed status indicator
  • Mouseover box with more details about the bug

Subtasks

action #27883: [tools] Deploy bug fetcher on proper VMResolveddheidler


Related issues

Related to openQA Project - action #10188: [tools][dashboard]Tracking open bugs based on product Resolved 12/01/2016

History

#1 Updated by dgutu almost 4 years ago

User story

When a failed test in openQA has a reference to opened bug we would like to know if the status of the bug changed from open to resolved for example.

Proposal

  • Maybe we can change to color of the bug, so the reviewer pay attention and check if the bug is really fixed.

#2 Updated by coolo over 3 years ago

  • Category changed from 124 to 140

this requires openQA to have an understanding what bugs are beside just a string that matches a regexp. But what you describe can (and IMO should) be implemented in the external review script. openQA should provide the info about the currently happing bugs (as in the test review comments) and bugzilla provides the state of it. Having an external tool that combines them and spits out that comment either for a reviewer to read (and possibly fix either side) or for all to read into the group overview.

OBS implements some kind of issue tracker and knowing how many code is required and how many problems we had to solve to get this going I sure would like to see a really good business case on how much time this saves us.

Especially taking that a resolved bug does not mean the next build will not have this problem - RESOLVED means basically nothing to QA, until the bug is gone and should be VERIFIED. So yes, if you care for verifying bugs, you want an enitity to have an overview of all databases. But I disagree that this entity should be openQA.

#3 Updated by okurz over 3 years ago

  • Related to action #10188: [tools][dashboard]Tracking open bugs based on product added

#5 Updated by okurz over 3 years ago

  • Assignee set to dheidler

"openqa_review" can read bugzilla issue status, subject and assignee since https://github.com/okurz/openqa_review/pull/8
https://w3.nue.suse.com/~okurz/openqa_suse_de_status.html shows the status for each bugref (as well as progress issues) so it got pretty easy to track which bugs are RESOLVED FIXED but still in the product.

Next step:

  • Customized reports based on that data, e.g.
    • all RESOLVED bugs but tests still fail
    • tests that fail but nobody cares about the bugs (e.g. "NEW" bugs for existing product issues)
    • bugs without assignees (or no personal assignees, only mailing lists)

#6 Updated by dheidler over 3 years ago

https://github.com/okurz/openqa_review/pull/26

openqa_review can now filter for closed bugs that are still in the product.

#7 Updated by dheidler over 3 years ago

  • Status changed from New to In Progress

#8 Updated by dheidler over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

#9 Updated by okurz over 3 years ago

  • Status changed from Resolved to In Progress

unfortunately it's not. "openqa-review" is a good approach but it's not openQA. Eventually openQA should be able to do this. Maybe start with the discussed openqa-review plugin for openQA.

#10 Updated by RBrownSUSE almost 3 years ago

  • Subject changed from [Feature] - make openQA show when a bug is marked as "RESOLVED FIXED" but still in the product to [tools][Feature] - make openQA show when a bug is marked as "RESOLVED FIXED" but still in the product

#11 Updated by RBrownSUSE almost 3 years ago

  • % Done changed from 100 to 40

While the openqa-review feature is nice, we really need the icons on the matrix view to also show the status of the bug in bugzilla. Its particually important to identify bugs which Bugzilla reports as closed but are still present in the product - These should probably be flagged with a red bug icon or something similar.

#12 Updated by RBrownSUSE almost 3 years ago

  • Subject changed from [tools][Feature] - make openQA show when a bug is marked as "RESOLVED FIXED" but still in the product to [tools][dashboard][Feature] - make openQA show when a bug is marked as "RESOLVED FIXED" but still in the product

#13 Updated by okurz almost 3 years ago

@dheidler: please extend the ticket with acceptance criteria

#14 Updated by dheidler almost 3 years ago

  • Description updated (diff)

#16 Updated by dheidler over 2 years ago

  • % Done changed from 90 to 100

#17 Updated by okurz over 2 years ago

The feature works great. We also have the documentation updated. What I suggest to do is to make sure the script that updates the bugrefs is not just running on dheidler's hidden workstation and better documented and also for o3.

#18 Updated by dheidler over 2 years ago

@okurz:

For o3 we need to find a solution how to deal with private bugs.

We could report them to o3 as non-existing. But that would result in
a wrong bug status info in the o3 db.

Or we could use a bugzilla account with access to private bugs
and let it return everything. Bug this could leak private data
so I would prefer the 1st solution.

#19 Updated by dheidler over 2 years ago

I created a new bugzilla account (o3bugfetcher) without employ status to fetch o3 bugs.
I updated openqa_bugfetcher so that it will skip the bugs that it can't access.
That means, that it will try to fetch that bugs again at every cron-call.
To avoid it DOSing bugzilla I only run the o3 bugfetcher every 10 hours - not every 10 minutes like osd bugfetcher.

#20 Updated by coolo over 2 years ago

  • Target version set to Ready

#21 Updated by coolo almost 2 years ago

  • Status changed from In Progress to Resolved

I claim this is resolved

#22 Updated by szarate almost 2 years ago

  • Target version changed from Ready to Done

Also available in: Atom PDF