action #88485
closedopenQA Project - coordination #102906: [saga][epic] Increased stability of tests with less "known failures", known incompletes handled automatically within openQA
openQA Project - coordination #88229: [epic] Prevent unintended test coverage decrease
action #88127: [tools][qem] Test coverage DB for maintenance updates
[teregen] Fetch and store coverage info for each incident
100%
Description
Motivation¶
Data about coverage can be found inside openQA and obtained via API. We need to solve the association between incident (on the openQA and template side) and source package (the actual "coverage" side).
A simple tool is needed to fetch aforementioned data via openQA API and store them in some lightweight database. The data to store should be merged with the already stored data (union of both datasets) as we are interested in maximum coverage.
Acceptance criteria¶
AC1: implement database storage/retrieval tool
AC2: maximum coverage needs to take the tested product/code-stream into account
AC3: include list of tests that are not running in test report
AC4: entries in DB are updatable for both adding new available coverage but also removing tests from the list
Suggestions¶
- Research available database backends
Updated by jbaier_cz almost 4 years ago
We have several options for the DB backend. As the main goal is to store JSON-like data without strong relations it might be good to evaluate NoSQL databases. We have probably following options:
- sqlite -- easy to setup, non-complicated use; SQL-like, might be slow
- redis -- very fast; not really meant for NoSQL data, more like key-value store
- CouchDB -- ideal for JSON data; currently not supported in Leap/TW
- MongoDB -- same as CouchDB; license problems
- RethinkDB -- similar to other NoSQL databases; meant for pushing data to real-time web applications
It seems, that for start we shall begin with sqlite and switch to another DB if the speed issue shows up.
Updated by okurz over 3 years ago
- Due date set to 2021-03-31
Setting due date based on mean cycle time of SUSE QE Tools
Updated by livdywan over 3 years ago
- Description updated (diff)
It seems, that for start we shall begin with sqlite and switch to another DB if the speed issue shows up.
Talking to Jan a bit, it seems like we may want to take advantage of the Postgres on qam2,so Postgres would make more sense now.
Updated by jbaier_cz over 3 years ago
- Status changed from In Progress to Resolved
Main functionality implemented in 85c7fedf.
Updated by jbaier_cz over 3 years ago
- Subject changed from Fetch and store coverage info for each incident to [teregen] Fetch and store coverage info for each incident
- % Done changed from 0 to 100
Updated by jbaier_cz over 3 years ago
- Related to action #90914: [teregen] Add overview for stored coverage data added