Show actual "version" in job groups for builds when configured + multiple versions are available
Our job groups already support multiple versions per job group however the job group page does not show the version, e.g. see https://openqa.opensuse.org/group_overview/17 which has builds for multiple versions of OBS like "Unstable", "2.9", "2.10", etc. Would be nice to have an option to also display the version in the "build" string. The duplicate #103557 has screenshots to show this problem as well with multiple build entries for the same build number because they differ by version.
- AC1: No duplicate build number entry on job group page for jobs with same build but differing version
- As soon as the same build number (or "build name") appears multiple times prepend the version to the build string.
#2 Updated by mkittler almost 3 years ago
We use the version already to sort anyways. This sounds easy to implement: The template rendering could simply generate a new headline as soon as the current version of the next bullet point changes.
Note that the index page uses is rendered by the same code. Should it also be affected? Should we hide the version if there is only one version?
#3 Updated by okurz almost 3 years ago
- Subject changed from Show actual "version" in job groups for builds when multiple versions are available to Show actual "version" in job groups for builds when configured + multiple versions are available
yes, I also think it's easy as we have the version readily available.
- index page: yes, should behave the same
- headline: either that or version+prefix, both should be fine
- hide version: yes, but might be configurable
I would still recommend to have an option that decides that, same as we have for group order preferences. If that makes it hard to influence the index page then apply to the job group only
#7 Updated by mgrifalconi 4 months ago
- Priority changed from Low to Normal
I would rather prefer to have the build number aggregated (see only one entry per day) and have that link point to the aggregate view and not adding info to multiple build numbers and service packs versions.
jctmichel also expressed the same preference during the QE Sync meeting on 05-01-2022
I would also raise the priority since this is impacting the usage of this new refactoring and more squads will suffer from it as the refactoring continues.
#11 Updated by mgrifalconi 4 months ago
- Priority changed from Normal to High
The adoption of the new job group format is increasing and with it the pain caused by the missing aggregate build view requested in comment #7
Therefore, I propose to increase priority.
More feedback from qac https://suse.slack.com/archives/C02CGKBCGT1/p1642365943011100
QE-Core will adopt this format during this week as well.
Maybe it's for another bigger ticket, but if I may suggest something, it would be nice that same build numbers are grouped together.
So, instead of having different entries for the same build (as you can see in the image)
would be good to have a single row with the build number, and then when clicking and going into the job list view, grouping them by version, the same view when using a url query like this:
- Status changed from New to Feedback
This is only about prefixing the version if it was otherwise ambiguous. That should fulfill AC1.
Grouping these as suggested in comments would be a little bit more work and we should define how that should work exactly. Are additional headings for each version enough or should there be a bullet point per version which is expandable to reveal the progress bars per build only when needed? The latter would be a little bit more work to implement, e.g. I suppose on "version level" the figures shown in progress bars needed to be accumulated similar to how it works already for parent groups. That brings me to the next question: Should this work for parent groups? If yes, I suppose that would mean two levels of grouping.