action #50846

Put reported bugs into own database

Added by vpelcak over 2 years ago. Updated about 1 year ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


ATM in openQA bugs are added to the comments and are treated so.

They do not have own database entries.

Therefore gathering any statistics about amount of reported bugs is non-trivial task.

Use case: How many bugs have we found using openQA in month X? How many in year Y? Which bugs are those?


#1 Updated by coolo over 2 years ago

  • Target version deleted (Ready)

(Picking the target version is my job).

There is a bugs table - fetched from bugzilla. And as bugs aren't reported on openqa, if they are labeled in openQA or not does not give you any useful statistic on 'how many bugs have we found'

#2 Updated by mkittler over 2 years ago

coolo already answered before I could submit my comment so my answer is a bit redundant:

There's actually a database table for bugs. However, it must be filled and updated via the API by an external script. So far this is done by the openQA bugfetcher script which tracks to my knowledge Bugzilla, GitHub, Progress and Jira. Since coolo explicitly requested to implement this as an external script at the time I suppose supporting this directly in openQA is not going to happen.

If you have access to openQA's database you should be able to get the answers to your 'Use case'-questions. But as coolo already pointed out the statistic wouldn't be very useful.

#3 Updated by vpelcak over 2 years ago


Sorry, I didn't know if and what Target Version should I choose.

What better approach do you propose to be able to gather bugs statistics then?

We definitely need to be able to measure how do we contribute to the product quality.

#4 Updated by mkittler over 2 years ago

Just don't set the target version at all.

What better approach do you propose to be able to gather bugs statistics then?

If the task is simply to find out "How many bugs have we found using openQA in month X?" the reviewers could maintain a table with all bugs they find using openQA. So if they find a bug they not only create a ticket in some bug-tracker but also add an entry to that table. That it would be a manual step is annoying of course. And bugs which turn out to be invalid or duplicates might be forgotten to be updated.

You could also try to flag bugs as 'found via openQA' in the bug-tracker systems we use and query their APIs directly to get the statistics. Those queries shouldn't be hard to implement. At least I remember that the mentioned openQA bugfetcher script wasn't that comprehensive.

Note that openQA is a test automation system but not a bug-tracker.

#5 Updated by cdywan over 2 years ago

Relying on the aforementioned script, I proposed a PR to expose the time of a bug having been reported (ie. added via a comment and thus recorded in the database).

#6 Updated by okurz about 2 years ago

  • Category set to Feature requests

#7 Updated by coolo about 2 years ago

  • Priority changed from Normal to Low

I don't see anything left to do here - please close

#8 Updated by okurz about 1 year ago

  • Status changed from New to Resolved
  • Assignee set to cdywan

no response from ticket reporter. I agree that there should be nothing left to do. cdywan added last steps.

Also available in: Atom PDF