Avoid hiding branch CI pipelines when detached pipelines are used

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem to solve

Right now the UX for the CI/CD pipelines when using Pipelines for Merge Requests it's quite confusing for us. Not only it hides the status from the regular pipeline, but it's also hard to keep track of them once the MR has a considerable amount of commits, especially if there are some pipelines with invalid yaml.

GitLab's sorting of pipelines in the merge request it's not really usable, as instead of just sorting the pipelines by id it orders detached pipelines independently (and also invalid yaml ones, although that seems to have been changed recently?)

I prepared a repository showcasing the main issue from my point of view, with some comments in the merge requests.

https://gitlab.com/alexviscreanu/mr-pipelines-ux/-/merge_requests

Intended users

Technically it would be any user that it's using GitLab CI and wants to take advantage of this feature. But if I'd have to select the most relevant ones it would be:

• Sasha (Software Developer)
• Devon (DevOps Engineer)
• Rachel (Release Manager)
• Priyanka (Platform Engineer)

User experience goal

To avoid using such a confusing UI approach for displaying the pipelines for merge requests. We haven't been able to use this feature mainly because of this.

Proposal

Use a similar approach as parent-child pipelines, where the whole status is displayed at once, and hide the unnecessary complexity of the detached pipelines from the user interface.

Something like this maybe?

Note: I'm keeping the branch pipeline as the relevant one as we mainly run things in regular pipelines, I guess some projects might be running more things on mr pipelines, in which case the roles can be reversed, and keep the mr pipeline as the main one, and just a summary of the branch pipeline inline, the same way as upstream or downstream pipelines.

I kept the detached label, although I must say that I don't really understand it, and I'd much rather have a different name.