Project

General

Profile

Actions

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.

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

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

Actions
Actions #1

Updated by jbaier_cz about 3 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:

  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.

Actions #2

Updated by okurz about 3 years ago

  • Due date set to 2021-03-31

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

Actions #3

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

Actions #4

Updated by jbaier_cz about 3 years ago

  • Status changed from In Progress to Resolved

Main functionality implemented in 85c7fedf.

Actions #5

Updated by jbaier_cz almost 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
Actions #6

Updated by jbaier_cz almost 3 years ago

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

Updated by okurz almost 3 years ago

  • Due date deleted (2021-03-31)
Actions

Also available in: Atom PDF