Link pipelines via merge commit
When I merge a merge request, it usually kicks off a new pipeline to then deploy that change. As the developer or PM watching the MR, I want to be able to follow along with that second pipeline. Unfortunately, they're completely independent pipelines today, and until the pipeline actually deploys the change, nothing changes on the MR. When it does finally deploy, you'll see the
Deploy to production on about.gitlab.com message in the MR widget.
What if we treated these two pipelines as connected, similar to how we're handling cross-project pipelines? e.g. Show the two pipelines as one long pipeline, joined this time by a merge commit (or FF merge action) rather than a cross-project link? Would be valuable in the pipeline detail page, but even more valuable in the mini graph that appears in the MR widget.
But with merge icons instead of play icons in between Upstream and Downstream pipelines.
The arrows could actually stay, I think.
Links / references
- Earlier proposal with similar goals: #17013
- Related proposal that will help as well: #25140
- Link between project pipeline views: gitlab-ee#2121 (closed)
(Write the start of the documentation of this feature here, include:
- Why should someone use it; what's the underlying problem.
- What is the solution.
- How does someone use this
During implementation, this can then be copied and used as a starter for the documentation.)
@markpundsack it seems a valuable idea, but if we use the connection what if we also have triggers to other pipelines? It could be fine to show all of them as they've different icons one the connections. But I still like to see a mockup with both downstream(s) and merge-related pipeline. @dimitrieh could you please see if you find a cool way to render this scenario?
For the type we already have
pipelines, we could have
mror something like that in
@bikebilly Note that @dimitrieh and I had a separate conversation about the MR page, and came up with an idea where we associate pipelines to a MR the same way we associate deployments to a MR. i.e. if the pipeline is the first pipeline for that ref that includes the SHA of the MR, then it's a related pipeline. This way, a MR would show two pipelines, one for the topic branch and one for the merged branch (after merge). If we go this direction, we couldn't need to explicitly link the two pipelines, as the current issue proposes. I'm honestly not sure which is a better approach, but I am sure that we should do something in this area.