Skip to content
Snippets Groups Projects

Link between project pipeline views

Resources

UX @dimitrieh FE @brycepj BE ?

Description

When projects are connected via triggers or dependencies, we should display those connections in the pipeline graph.

Proposal

  • Show inbound and outbound connections for upstream and downstream pipeline dependencies.

Note, this is not about showing artifact, image, submodule or other dependencies. It's about what pipelines cause other pipelines to run.

This is the first iteration, extended version would be the consolidated view https://gitlab.com/gitlab-org/gitlab-ce/issues/22558

proposal-image

Design

img

  • hoverstates are the same as on regular nodes, the nodes are just more square!
  • on hover tooltip: Full project name - status

bonus for visualisation in mini pipeline graph:

image

When hovering or clicking (mobile) they will expand and be shown next to each other. If there are too many we can show them like:

image

on hover tooltip: Full project name - status

gif

  • prototype url https://framer.cloud/VPXRP
  • for mobile the expansion of multiple downstream icons is on tap, rather than hover (if it feels better on desktop as well, please do that 😉 )
  • note: that the status icons for upstream and downstream projects are a little smaller and have an extra white outline border to make them not blend

Links / references

Documentation blurb

In modern organizations, most products are the output of interactions between different services and components. For this reason, with the rising of CI/CD as the standard development workflow, there is a growing need for pipelines of different projects to interact one with each other. These links must be clearly shown in a place where developers can easily figure out the big picture.

In order to address this task, we're introducing an enhanced pipeline view that also contains the other involved pipelines, where relationships are automatically detected by mean of triggers. This view doesn't need that relationships are previously defined somewhere outside, keeping it simple and preserving the independence of each single project involved.

Users can then run triggers on other projects using the gitlab-ci.yml and monitoring the complete chain of pipelines directly from a single view.