Project

General

Profile

Actions

action #92533

open

coordination #99306: [epic] Future improvements: Make reviewing openQA results per squad easier

Module-centric test result overview

Added by MDoucha over 3 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
QA (public, currently private due to #173521) - future
Start date:
2021-05-11
Due date:
% Done:

0%

Estimated time:

Description

In response to the discussion about OpenQA review process changes, I'd like to propose a new test result overview that is module-centric. All current overviews are job-centric which makes it difficult to compare the results of a single module under different configurations.

Requirements:

  • Show all available results of a single test module on the same page
  • Renamed instances of the same Perl module will be treated as different modules but there will be quick navigation links between them
  • Filtering and easily configurable grouping by standard OpenQA job filters (distri, arch, flavor, etc.)
  • Filtering by module result (passed/failed/softfailed/skipped/none)
  • Result grouping by test version (package version or Git commit)
  • Option to show only the latest results (per job group/build) or everything
  • Quick link to parent OpenQA job from each module result
Actions #1

Updated by MDoucha over 3 years ago

Actions #2

Updated by MDoucha over 3 years ago

Note: I'm willing to write this test overview myself in Django. But I'll need read-only access to OpenQA database. OpenQA also seems to be missing a database field for module versions, that needs to be added first.

Actions #3

Updated by okurz over 3 years ago

  • Target version changed from Ready to future

MDoucha wrote:

Note: I'm willing to write this test overview myself in Django. But I'll need read-only access to OpenQA database.

For OSD there is https://confluence.suse.com/pages/viewpage.action?spaceKey=openqa&title=openQA#openQA-Accessingthedatabase with read-only access to the openQA database.

OpenQA also seems to be missing a database field for module versions, that needs to be added first.

you mean like the git hash corresponding of test code that corresponds to the module results? In that case I would prefer if the job to which a test module belongs stores this information. See #58184 as a related feature request saga. So far I solve this by downloading the vars.json file of the corresponding job and reading the test git hash from there.

Actions #4

Updated by okurz over 3 years ago

  • Parent task set to #91914
Actions #6

Updated by rpalethorpe about 3 years ago

I have started a related project to port the useful parts of JDP (i.e. bug tagging) to Django/Python: http://10.162.187.174:8080/

Actions #7

Updated by rpalethorpe about 3 years ago

Metabase seems to resolve this adequately.

Actions #8

Updated by okurz over 2 years ago

  • Parent task changed from #91914 to #99306
Actions

Also available in: Atom PDF