Project

General

Profile

action #53264

Show actual "version" in job groups for builds when configured + multiple versions are available

Added by okurz almost 3 years ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2019-06-18
Due date:
2022-02-02
% Done:

0%

Estimated time:
Difficulty:

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.
wicked_view.png (48.4 KB) wicked_view.png jlausuch, 2022-01-19 12:10
12412

Related issues

Has duplicate openQA Project - action #103557: Aggregate different versions into the same build openqa in group_overview pagesRejected2021-12-06

Copied to openQA Project - action #105118: Combine builds for multiple versions depending on configurationRejected

History

#1 Updated by hennevogel almost 3 years ago

Or to group the builds by version under a headline.

#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

#4 Updated by okurz almost 2 years ago

  • Target version set to future

#5 Updated by okurz 5 months ago

  • Has duplicate action #103557: Aggregate different versions into the same build openqa in group_overview pages added

#6 Updated by okurz 5 months ago

  • Description updated (diff)

#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.

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.

#9 Updated by okurz 4 months ago

I guess your approach is a valid alternative. I can see the use case in both. We might need to make that configurable.

#10 Updated by okurz 4 months ago

  • Description updated (diff)

#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.

#12 Updated by okurz 4 months ago

  • 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.

#13 Updated by jlausuch 4 months ago

12412

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.

#14 Updated by okurz 4 months ago

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

#15 Updated by mkittler 4 months ago

  • Assignee set to mkittler

#16 Updated by mkittler 4 months ago

  • 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.

#17 Updated by okurz 4 months ago

  • Copied to action #105118: Combine builds for multiple versions depending on configuration added

#18 Updated by okurz 4 months ago

  • 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.

#19 Updated by mkittler 4 months ago

  • Status changed from Feedback to Resolved

PR has been merged and deployed on OSD. On https://openqa.suse.de/group_overview/412 it is working so AC1 is fullfilled.

Also available in: Atom PDF