QA

Motivation¶

For QAM incident tests we should consider using flavor rather than build to encode incident+test to ensure that

• "Next & previous" results only show results for the very same incident, not all different kind of packages
• openQA can resolve the real "latest" result per incident on /tests/overview, e.g. to make reports on https://openqa.io.suse.de/openqa-review/ more useful for incident tests as well
• label carry over works for repeated failures within the same incident

Acceptance criteria¶

• AC1: openQA "Next & previous" for any incident test only shows jobs for the same package
• AC2: The test overview link on https://openqa.suse.de/parent_group_overview/8#grouped_by_build shows still results from multiple incidents for multiple product versions at the same time

Suggestions¶

• Without changing the build variable we could try to just add the package (maybe also the incident number) to flavor. Likely this needs to be done in qa-maintenance/openQABot (or the metadata project)
• To avoid confusion, this is about links that are generated in a previous part but no the webui "next & prev"
• One example: https://openqa.suse.de/tests/6511087#next_previous shows how we treat all different kind of incidents for different packages as the "same scenario" because flavor is always "Server-DVD-Incidents" here, only build differs. What we could do is change the flavor in this case for build ":20484:spice-vdagent" to "Server-DVD-Incidents:20484:spice-vdagent" but if we set the different flavor then we likely don't trigger any tests anymore :( Should we remove anything after a special token like ":" and don't consider for scheduling? Maye introduce another optional, custom "external reference" field? or "flavor tags"? :) As alternative maybe use a custom version suffix and ensure that the "fallback version product pattern matching" still works, using the asterisk "*" in a version field.