For GitLab CI, Pipelines is far more important than Builds. I really don’t know about the Jenkns or other integrations. If we’re treating Pipelines as a synonym for CI, then putting Jenkins under Pipelines is fine.
Pipelines will show a list of past pipelines run for this project
Builds will always be handy, because you sometimes want to quickly see what did fail for this MR. Maybe good addition would be to show what is important here? Actually a failed builds for latest pipeline?
@ayufan I feel like the Builds list just needs to go away. :) CircleCI and Travis don't have such a thing and no one has ever asked for it. Worst case is that the info is now an extra click away. But if there's some value it provides, perhaps we should redesign the Pipelines list to provide that value. For example you say "sometimes you want to quickly see what failed for this MR". That's exactly what the stages in the pipelines view are trying to achieve. In fact, in some ways, it already is clearer. But where it fails is that it reduces X parallel jobs to a single checkmark or X. But if clicking on that X brought you directly to the build(s) that failed, then perhaps it would be a reasonable replacement. Or perhaps we need to include which jobs failed in that view? Is it important to know if it was a spinach job vs an rspec job? Maybe show more detail on hover? Or just link to the first failure and then on that resulting page, make it easy to jump to subsequent failures.
Currently, when you click on the X, you just see the build list, but with the failed job as an anchor. I've found that less than valuable myself several times and wish it went directly to the build log of the bailed job.
If it really is important for people to jump to a list of builds for the current pipeline run, there's always the build status that shows up right above the merge button. Clicking View details should bring you to the most recent pipeline .../pipelines/X rather than .../merge_requests/Y/builds.
My gut is that once we provide a Pipelines view for MRs, most people will prefer that. And for those that don't, we can (and should) improve the Pipelines view so they end up preferring it.
FWIW, I'm willing to leave Builds there for now, so people have time to transition. We could add Pipelines this release, and then remove Builds in another release or two.
@ayufan IIRC, in the builds tab you should all builds related to the last commit (at least this is was we see by default, if I'm not mistaken). I think the pipeline view should show all pipelines for the latest commit too. IMHO, this is what usually matters.
That is what usually matters, but sometimes its valuable to see the history as well. For example, when working collaboratively on a MR, if the current status is failed you might want to go back and see if it's just the last commit that broke, or if it was broken earlier, by someone else.
Also, simply, there's usually a much smaller number of pipelines and showing multiples isn't really a problem. But showing all builds would be confusing. You need to limit to the current commit in order for the builds list to be meaningful.
We need a new tab, Pipelines, in between Commits and Builds which will show something like, but with the branch name removed since that is the same for all pipelines in this view, and it is shown above:
When the user clicks through on a pipeline, it should go to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5446/pipelines/3769217, which would look a lot like the current builds list, but support showing non-current pipelines.
[I struggled trying to not need these similar, but oh-so-slightly different views, but I can't. They deserve having different navigation, yet the same content.]
Also, in the project MR list, there's currently a pipeline status icon that links directly to the pipeline detail page.
We should change that to link to the same pipeline, but nested under the MR resource, so we get intra-MR navigation. e.g. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5446/pipelines/3769217