Project

General

Profile

action #92533

QA - coordination #91646: [saga][epic] SUSE Maintenance QA workflows with fully automated testing, approval and release

coordination #91914: [epic] Make reviewing openQA results per squad easier

Module-centric test result overview

Added by MDoucha 5 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2021-05-11
Due date:
% Done:

0%

Estimated time:
Difficulty:
medium

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

History

#1 Updated by MDoucha 5 months ago

#2 Updated by MDoucha 5 months 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.

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

#4 Updated by okurz 5 months ago

  • Parent task set to #91914

#6 Updated by rpalethorpe about 1 month 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/

Also available in: Atom PDF