Show jobs in context of pipeline
Description
When looking at a build, we currently render related builds in a horizontal, wrapping list. After gitlab-foss#18516 (closed), we'll compress that build list a bit, and group them by stage. After gitlab-foss#18141 (closed), we'll have a pipeline graph of all builds and stages in the pipeline.
When transitioning from a pipeline to a build, it's a bit jarring. You lose the pipeline graph, which kind of acts as a map. You can quickly navigate to other builds in the pipeline, but wouldn't it be better to use the pipeline graph as a navigation map? Also, there's meta and ambient information about the pipeline that is lost. From purely an IA perspective, it's a bit weird to navigate to peer-level items rather than treating the pipeline like a parent of the build. Lastly, from a jobs-to-be-done perspective, why are people drilling into these pages anyway? One reason is they're tying to determine if a merge request should be merged despite the pipeline failing due to flaky tests. So navigating from MR to Pipeline to Build requires someone to go back through their browser history (or find a link to the MR somewhere on the build page).
We should render builds in the context of the pipeline. A good solution would not take up an inordinate amount of vertical space and would add value by providing better navigation between builds, and an improved understanding of the build and pipeline.
Proposal
Links / references
Activity
Original proposal from https://gitlab.com/gitlab-org/gitlab-ce/issues/18141#note_12234793:
With improved mockup from @hazelyang in https://gitlab.com/gitlab-org/gitlab-ce/issues/18141#note_12981603:
The problem was the large amount of vertical space taken up for the graph when a user is just trying to look at a build log. One collapsing graph proposal:
Another is to just hide the graph altogether by default, but let the user expand it:
We ended up settling on a two-row view, showing stages and jobs as tab selections, using existing UI elements.
This is functional, but feels a bit disjointed.
All along we assumed just keeping the graph would be really bad, but thinking about it more, for a LOT of users, their pipeline graph is going to be small, so keeping it around might not be that bad. And with collapsing parallel builds, even
gitlab-ceonly shows 13 rows of jobs under the Test stage. So first off, maybe this would "just work" and we were overcomplicating the problem.But, assuming showing the full graph is not great, let's revisit how to show a collapsed graph. I tried a design where we collapsed it to a graph of the stages, but broke out the jobs in that stage in a second line:
It's basically where we ended up, but with more of a graph feel to the stage list. I didn't like it though, because it wasn't really the same as the pipeline graph. Specifically, in the pipeline graph, the oval nodes were jobs with text titles for stages, but in the above mockup, the stages are in the ovals. This means transitioning from one view to the other is still jarring. Imagine clicking on a node in the pipeline graph and then going to the build page, it wouldn't really feel completely related.
Talking with @annabeldunstone today, I realize there's another option. We have a design for collapsing parallel jobs into a single node in the graph.
What if we extend that pattern to collapse all of the jobs to a single node in each stage. If there is only one job, then just display the name. If there are multiple jobs, but you've currently selected one, then show the selected job, with a dropdown to navigate to others. If there are multiple jobs, but none are selected (because you've selected something in a different stage), then show "64 jobs" with a dropdown arrow.
This works great for really simple pipelines where there's only a single job in each stage. There would be no collapsing at all. And the whole graph might actually be smaller than our current two-row solution.
For pipelines with parallel jobs, I hope it will feel fluid. You click on a job in the pipeline graph and the graph collapses and shows the build details below. Then to navigate to another build in that stage, you click on the dropdown. We could even allow people to collapse/expand the graph themselves. Ad we could consider not collapsing by default if there's less than X parallel jobs. Say up to 4 jobs will show the expanded graph by default, but above that, we collapse by default. Or remember whether a user has expanded it or not, and keep state between views. The important part is that the expanded and collapsed views would flow better because they look very similar, so it's no longer a jarring transition.
Edited by Mark Pundsack@tauriedavis Would love your thoughts on the above.
mentioned in issue gitlab-foss#18141 (closed)
This is kinda what I'm thinking. Some details are off, but should be enough to convey the gist.
Edited by Mark Pundsackcc: @dimitrieh
mentioned in issue gitlab-foss#21277 (closed)
@markpundsack what is your view on this with the current sidebar design?
This shows the pipeline in an abstract way that doesn't obfuscate anything from the actual builds tab. Actually if we would show the pipeline in one way or another in the same view as this sidebar, duplication of content may confuse users imo.
Just a thought of what could be done is improving the dropdown of the sidebar... making is more visual.. as that is the target of this issue I feel.
becomes for example:
Another option would be to do away with the whole dropdown and let the list be more like the pipeline, including the ability to fold open/close sub tests of a stage
Edited by Dimitrie Hoekstra@dimitrieh I don't know. :) I agree that showing two different views of the same thing would be bad. So it seems like we either stick with the drop-down, possibly with enhancements, or we go with the pipeline graph view, but not both.
-
@markpundsack I want to come back to this, as the original issue is showing builds in context of the pipeline, instead of showing pipelines in context of builds.
And we "should" imo, in the light of this comment: https://gitlab.com/gitlab-org/gitlab-ce/issues/21454#note_15010563
What if we could open the builds inline in the pipeline view:
quick mockup.. wondering about a button instead of "caret". This is below the pipelines view.
As for showing pipelines in context of pipelines: what about doing away with the dropdown? Just letting it be a long list, with some hierarchy
perhaps with sticky element for "stage" header while scrolling:
cc: @hazelyang
@dimitrieh So both of those were suggested before and the pros/cons were discussed. :) Can you explain why you're suggesting them? If there's some new insight, I'd be happy to revisit, but don't want to just rehash them again.
@dimitrieh Just throwing this out there, but if we go with the simplified pipeline graph from https://gitlab.com/gitlab-org/gitlab-ce/issues/21925, it's small enough to fit in the sidebar of a build log. Not sure that really helps, but you could replace the stage dropdown with the simplified graph and let people click on/touch each stage in the graph to select the jobs below. That might also address the spirit of this issue, which is to retain some context of the pipeline when looking at a build.
-
@markpundsack I think this issue is named wrong... as it should state showing pipeline in context of builds
I think we should stay with the abstract... in other words the build list. because:
- the graph does not support retried builds
- the sidebar is the best place for this.. as we want the build log to be the primary information block.
The stage names with sticky headers in the builds list is I think the better implementation which I mentioned here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20863#note_15028161 because:
- it keep clicks away.. just scrollllllll
- shows everything in one context (a little like the graph) instead of breaking it up by means of a dropdown.
cc: @tauriedavis
@dimitrieh I don't really want to debate the grammar, but the title makes sense to me, as-is. :)
But perhaps what you're saying is that this issue isn't important. Let the build detail page focus on the build, and use the sidebar for navigating to other builds. For that, we already have a reasonable solution, but your suggestion of hierarchical scrolling list with sticky headers is an interesting improvement. It will make it more difficult to switch between stages since there could be a lot of scrolling needed. Probably should be separate issue. :)
-
@markpundsack good thinking and yes I agree
It will make it more difficult to switch between stages since there could be a lot of scrolling needed.
I don't agree with removing the dropdown for this reason. I don't understand how this change would be more user-friendly than the current implementation.
Edited by Taurie Davis-
@tauriedavis I believe you are agreeing with mark isn't it? or am I misinterpreting?
-
I'm not sure, his opinion is unclear to me because he said it is an interesting improvement.
I am just saying I don't think we should remove the dropdown in favor of scrolling for the reason that he stated: It will make it more difficult to switch between stages since there could be a lot of scrolling needed.
Mentioned in issue gitlab-foss#22499 (closed)
Mentioned in issue gitlab-foss#19703 (closed)
Mentioned in issue gitlab-foss#24339 (closed)
Mentioned in issue gitlab-foss#23785 (closed)
-
@markpundsack what do you think about this issue?
jenkins just updated their product with the following:
Entertain the idea of getting rid of job pages as a whole (or only keep them if a user wants to deeper inspect a job) and direct link from the mini pipeline graph to the job log within the pipeline view inside the job list..
It also fits in nicely with making the job log itself a scrollable container.
mentioned in issue gitlab-foss#27897 (moved)
@dimitrieh My current thinking is to focus more on the mini graph rather than the full graph. Putting both job logs and the mini graph on the same page should be quite doable, and add a lot of value. Navigating the stages/jobs in the sidebar is annoying.
I wonder if Jenkins Blue Ocean works because pipelines naturally have fewer parallel jobs... As in that screenshot, with only 4 parallel jobs, it already takes up quite a bit of vertical space. When you've got 10+ or 40+, it gets pretty crazy! Then again, I'm sure there's a solution for that too, as long as you let people scroll down and then focus on the log section and they never need to scroll back up when jumping between jobs or looking at meta information.
But, the mini graph, or something like my earlier mockup in https://gitlab.com/gitlab-org/gitlab-ce/issues/20863#note_13820802 still feel like the better way to go. Actually, going back to that earlier mockup (which is a collapsed graph but with bigger ovals than the mini graph), it now feels a bit more feasible since if we make the terminal fixed size and optimize the top content (which has already been done, iirc). I bet if you were to redo that mockup with the current design, it would look pretty solid.
mentioned in issue gitlab-foss#31718 (moved)
mentioned in issue gitlab-foss#34696 (closed)
moved from gitlab-foss#20863 (moved)
