Improve clarity of "detached" label/state, merge request pipelines feature
Problem to solve
The "detached" label on pipelines is not clear and needs a rethink so that the UX is clear. The detached state means that it was a merge request pipeline, so ran in the context of the merge request, but did not run "attached", which means against the merge request result. The label serves to drive awareness of this status, but is mainly creating confusion now.
The documentation is also insufficient and does not explain this correctly. It only says
Pipelines tagged with the detached badge indicate that they were triggered when a merge request was created or updated. and then a bit further down the following:
There are some cases where creating a combined ref is not possible or not wanted. For example, a source branch that has conflicts with the target branch or a merge request that is still in WIP status. In this case, the merge request pipeline falls back to a “detached” state and runs on the source branch ref as if it was a regular pipeline.
The detached state serves to warn you that you are working in a situation subjected to merge problems, and helps to highlight that you should get out of WIP status or resolve merge conflicts as soon as possible.
We also have confusing messages like the following:
This is a broad set of users who interact with pipelines. They can see the status and be confused.
Originally implemented in gitlab-ee#7380 (closed) and documented at https://docs.gitlab.com/ee/ci/merge_request_pipelines/#pipelines-for-merged-results-premium.
Add tooltip clearly explaining what this is, and/or consider renaming the label. Update documentation to be more complete at the same time.
Permissions and Security
As mentioned above, this does require a documentation update
There is possibility of UX testing to confirm this is more clear
What does success look like, and how can we measure that?