Project

General

Profile

action #88485

openQA Project - coordination #39719: [saga][epic] Detection of "known failures" for stable tests, easy test results review and easy tracking of known issues

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 9 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2021-02-08
Due date:
% Done:

100%

Estimated time:

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

Related to QA - action #90914: [teregen] Add overview for stored coverage dataNew2021-04-09

History

#1 Updated by jbaier_cz 9 months 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:

  1. sqlite -- easy to setup, non-complicated use; SQL-like, might be slow
  2. redis -- very fast; not really meant for NoSQL data, more like key-value store
  3. CouchDB -- ideal for JSON data; currently not supported in Leap/TW
  4. MongoDB -- same as CouchDB; license problems
  5. 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.

#2 Updated by okurz 7 months ago

  • Due date set to 2021-03-31

Setting due date based on mean cycle time of SUSE QE Tools

#3 Updated by cdywan 7 months 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.

#4 Updated by jbaier_cz 7 months ago

  • Status changed from In Progress to Resolved

Main functionality implemented in 85c7fedf.

#5 Updated by jbaier_cz 7 months 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

#6 Updated by jbaier_cz 7 months ago

  • Related to action #90914: [teregen] Add overview for stored coverage data added

#7 Updated by okurz 5 months ago

  • Due date deleted (2021-03-31)

Also available in: Atom PDF