action #53264
closed
Show actual "version" in job groups for builds when configured + multiple versions are available
Added by okurz almost 5 years ago.
Updated over 2 years ago.
Category:
Feature requests
Description
Motivation¶
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.
Acceptance criteria¶
- AC1: No duplicate build number entry on job group page for jobs with same build but differing version
Suggestions¶
- As soon as the same build number (or "build name") appears multiple times prepend the version to the build string.
Files
Or to group the builds by version under a headline.
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?
- 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
- Target version set to future
- Has duplicate action #103557: Aggregate different versions into the same build openqa in group_overview pages added
- Description updated (diff)
- 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.
Example of bad view https://openqa.suse.de/group_overview/405
What I would like the only build number per day to point to: https://openqa.suse.de/tests/overview?groupid=405
@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.
I guess your approach is a valid alternative. I can see the use case in both. We might need to make that configurable.
- Description updated (diff)
- 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.
- Priority changed from High to Normal
- Target version changed from future to Ready
Based on the above comments and discussion in weekly QE sync 2022-01-19 adding to backlog.
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: groupid=X&groupid=Y&groupid=Z.
@jlausuch I suggest that we first focus on the easier step to just include the version in the build displayed. After that we can look into multiple additional but also more advanced use cases
- Status changed from New to Feedback
PR: https://github.com/os-autoinst/openQA/pull/4462
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.
- Copied to action #105118: Combine builds for multiple versions depending on configuration added
- Due date set to 2022-02-02
Let's continue brainstorming about combining multi-version builds in #105118 . Here we should focus on the original idea and what you have covered with the PR.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF