action #88485
closed
openQA 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
Added by jbaier_cz about 3 years ago.
Updated almost 3 years ago.
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
Related issues
1 (1 open — 0 closed)
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.
- Due date set to 2021-03-31
Setting due date based on mean cycle time of SUSE QE Tools
- 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.
- Status changed from In Progress to Resolved
Main functionality implemented in 85c7fedf.
- 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
- Related to action #90914: [teregen] Add overview for stored coverage data added
- Due date deleted (
2021-03-31)
Also available in: Atom
PDF