coordination #95857
Updated by okurz over 3 years ago
## 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.