Project

General

Profile

Actions

action #12092

closed

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

Added by dgutu over 8 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Feature requests
Target version:
Start date:
2017-11-18
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)

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 1 (0 open1 closed)

action #27883: [tools] Deploy bug fetcher on proper VMResolveddheidler2017-11-18

Actions

Related issues 1 (0 open1 closed)

Related to openQA Project (public) - action #10188: [tools][dashboard]Tracking open bugs based on productResolveddheidler2016-01-12

Actions
Actions #1

Updated by dgutu over 8 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.
Actions #2

Updated by coolo over 8 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.

Actions #3

Updated by okurz about 8 years ago

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

Updated by okurz about 8 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)
Actions #6

Updated by dheidler about 8 years ago

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

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

Actions #7

Updated by dheidler about 8 years ago

  • Status changed from New to In Progress
Actions #8

Updated by dheidler about 8 years ago

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

Updated by okurz about 8 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.

Actions #10

Updated by RBrownSUSE over 7 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
Actions #11

Updated by RBrownSUSE over 7 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.

Actions #12

Updated by RBrownSUSE over 7 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
Actions #13

Updated by okurz over 7 years ago

@dheidler: please extend the ticket with acceptance criteria

Actions #14

Updated by dheidler over 7 years ago

  • Description updated (diff)
Actions #16

Updated by dheidler over 7 years ago

  • % Done changed from 90 to 100
Actions #17

Updated by okurz about 7 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.

Actions #18

Updated by dheidler about 7 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.

Actions #19

Updated by dheidler about 7 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.

Actions #20

Updated by coolo about 7 years ago

  • Target version set to Ready
Actions #21

Updated by coolo almost 7 years ago

  • Status changed from In Progress to Resolved

I claim this is resolved

Actions #22

Updated by szarate almost 7 years ago

  • Target version changed from Ready to Done
Actions

Also available in: Atom PDF