action #92533
openQA - coordination #99303: [saga][epic] Future improvements for SUSE Maintenance QA workflows with fully automated testing, approval and release
coordination #99306: [epic] Future improvements: Make reviewing openQA results per squad easier
Module-centric test result overview
0%
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
Updated by MDoucha almost 3 years ago
- Related to coordination #91914: [epic] Make reviewing openQA results per squad easier added
Updated by MDoucha almost 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.
Updated by okurz almost 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.
Updated by rpalethorpe over 2 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/
Updated by rpalethorpe over 2 years ago
Metabase seems to resolve this adequately.