pipeline comments to identify distinct passes through the .gitlab-ci.yml pipelines
Release notes
Current practice with .gitlab-ci.yml involves multiple threads of execution and potentially multiple threads aggregated into multiple "moral" pipelines all jammed together in the same file. While this is potentially acceptable for pipeline developers, the resulting "pipelines" UI page is extremely confusing since there's no visual distinction between these different "moral" pipelines other than perhaps the tooltip over jobs and the number of job bubbles.
Problem to solve
How do we distinguish between separate "moral" pipelines on the pipelines UI page? How does a user recognize which pipelines are associated with his commit?
Intended users
Intended users are twofold. Firstly, the DevOps engineer who creates these distinct "moral" pipelines and secondly, everyone else who might use the pipeline UI page in order to determine what's going on.
User experience goal
The goal here is that when someone looks at the pipelines UI page they can immediately, visually, determine which pipelines belong to which "moral" aggregate pipelines.
Proposal
The proposal is that pipelines include a brief comment, perhaps a single word or short phrase. Things like "presubmit check" and "nightly build (1/2)". These should be optional and, if present, should result in a separate column on the pipelines UI page, (perhaps optionally colored rows?)
I have also frequently wanted to see $CI_PIPELINE_SOURCE listed on that page so that should either be an optional separate column or it should be very easy to make $CI_PIPELINE_SOURCE be the pipeline comment.
Further details
I'm currently working with a project that has at least 6 different types of passes through the project pipeline. Simple things like "bail early" in a single moral pipeline require multiple passes through the project pipeline to make decisions about the code flow through the rest of the pipeline whether those are decisions about possible child sub-pipelines, generated subpipelines, or simple decisions setting local variables for subsequent passes through the main pipeline. The net result is dozens upon dozens of literal pipelines on the pipeline UI page representing only a small number of "moral" pipelines, each composed of multiple literal pipeline phases. This is confusing.
Permissions and Security
Nothing new here. Setting a pipeline comment is already covered by existing pipeline setup security.
Documentation
No new permissions. The documentation change would be the specific keywords or triggers involved in the .gitlab-ci.yml documentation.