New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always have detailed build status, and improve the detailed build status (or revert to previous implementation) #15932
Comments
Actually the bars are clickable.. but it opens a new tab for me. whats the logic between "showing bars" and "showing table"? I am not seeing the pattern |
What decides on which of the summaries of build results is visible, is hard cutoff of build results right here: https://github.com/openSUSE/open-build-service/blob/master/src/api/app/components/chart_component.rb#L5 which is then used in this condition: https://github.com/openSUSE/open-build-service/blob/master/src/api/app/components/chart_component.html.haml#L9 |
What @hellcp-work is trying to say is that "complicated to understand" build setups (more than 5 repositories and more than 12 builds) show the graph. Everything not so "complicated to understand" shows the table. |
@hellcp-work ah, thanks. I can see this is a potential solution for "requests that have many repositories". I would prefer to have a way to show "important repos" (with some logic to determine which those are) and then have a link for "more" that shows the rest (either as new tab or by unfolding a larger table). the bars are pretty, no doubt, but they don't help me decide "is the red here important or not important, is it new or not new?" |
@dirkmueller would you go as far as hiding the other repositories? |
@hennevogel there are multiple approaches. one could have a "more.." link, or just show the diff, and a "all the status" link that shows the full table. I'm not sure which one is better. personally I don't mind scrolling a bit more (I really mind clicking though) |
@dirkmueller sure there are always multiple approaches :) Not looking for advise what to do, looking for hints what is most important to you as reviewer (I guess that's your role here?) |
Is your feature request related to a problem? Please describe.
Sometimes the new request workflow shows a "bar graph" for the build results, with red green yellow colored bars and weird axis (like fract numbers, even though there can only be integers). this view is very unuseful to me, for two reasons:
none of those bars are clickable to filter for just that group.actually they are, but they open a new tab that requires further clicks to see then the results. don't make me click! ;)to be honest, I would always want to have the table view that is also sometimes appearing but less often. However, also the table view is a significant downgrade over the previous implementation for multiple reasons:
Describe the solution you'd like
Restore the previous build view. it was working fine. if you want to improve it, then highlight the primary repository for this request. For example if the sources are a link against
openSUSE:Factory
, then highlight the repository that is building againstopenSUSE:Factory
because the build results for those should be "gating/deciding" whether or not to accept the request.Also it could be a useful to show the "diff", aka is this request fixing the build anywhere or introducing a build failure anywhere compared to the request destination. That would be useful piece of information to visualize.
The text was updated successfully, but these errors were encountered: