Link pipelines that are related across commits/triggers
Description including problem, use cases, benefits, and/or goals
Developers want to visualize their code changes moving through a pipeline. e.g. build, test, staging, production. We have a Pipelines view which visualize this for pipeline movement, but it is based on a single commit, merge, or tag. When a merge request is merged, a new commit is created and a new CI run is started. Additionally, when branches are merged, say between develop
and master
or master
and 8.8.0
, these are all treated as separate CI builds. GitLab should understand that these triggers are related and thus their CI builds are related.
This is not a complete list of needs, but some things I know:
- As a developer, I want to be able to follow a CI run across the entire pipeline. (I don't know if this needs to be a single view or links between related views.)
- As a developer, I want to know when a merge request gets deployed to staging and production.
- As a developer or ops, I want to know what is currently running in production (or any given environment).
- As a developer or ops, I want to see a history of what merge requests have been deployed to production. (While this would be cool, it might be technically too difficult.)
Proposal
- On the Pipelines page, include links to related builds (especially useful for cross-project builds)
- Or on the Pipelines page, report related builds as a single, continuous line (especially useful for deploys within a project)
- On the merge request page, the activity should include related deploys.
- On the environments page, display the current SHA along with the related merge request, if there is one.
- On the list of merge requests, include the current deployment or pipeline state
- e.g. a badge indicating if it went to production
- Perhaps indicate the final pipeline stage so you can tell which MRs got to unit testing vs integration testing
Complications
It's common to merge several MRs before deploying to production. How would we link those? Would we really want to traverse a long history of builds to find all merged MRs that are included in the new deployment? It could be something equivalent to git log production..master
, turning all the included git SHAs into an array and then looking for all builds related to those SHAs. One problem would be rollbacks or reverts. We might be able to tell when a MR was first deployed to production, but determining if it's removed from production seems a bit harder. Perhaps that's totally unnecessary though.
Links / references
- From discussion on #3743 (closed)