openSUSE / open-build-service

Build and distribute Linux packages from sources in an automatic, consistent and reproducible way #obs

Home Page:https://openbuildservice.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Always have detailed build status, and improve the detailed build status (or revert to previous implementation)

dirkmueller opened this issue · comments

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:

  • the order of the repositories appear random rather than predictable, so looking for "is it building for Tumbleweed?" seems to be a more difficult question to answer
  • 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:

  • the repositories are not cleanly separated visually by lines
  • it does not hide excluded or disabled repositories
  • it hides the link to rpmlint and other build results
  • getting to the repository download path to check the build results is not possible anymore.

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 against openSUSE: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.

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?)