Add a custom name to pipelines during runtime
Current Status 2023-01-23
Add custom names to pipelines with `workflow:na... (#372538 - closed) is now generally available (in 15.8). It was shipped in 15.7 behind a default-on feature flag. The feature flag was removed in 15.8.
Current Status 2022-12-20
To solve for an internal customer use case a team member at GitLab opened and started work on Add custom names to pipelines with `workflow:na... (#372538 - closed). This is scheduled to ship in the 15.7 milestone. The feature is behind a feature flag that is on by default.
Status Update 2022-04-15
We have validated some use cases (in the description of this issue and Add custom labels to CICD pipelines (#26618)) exist that this would be a solution for. Our next steps will be to draft some solutions to review as part of workflowsolution validation. We would like to talk to users managing medium to large GitLab instances primarily (200 or more users ideally). We are not currently scheduling this validation and will announce here when we do as well as the team's letter from the editor which details our current priorities.
Release Notes
Users can now add custom names or descriptions to pipelines, making it easier to identify and distinguish between different pipeline runs, especially in projects with multiple pipeline types or configurations. For e.g. the following can be added to the CI configuration
workflow:
name: "$CUSTOM_PIPELINE_NAME"
Problem to solve
To explain this proposal I'd like to give a little context first:
Currently I got a repo which houses a project that can build products for different clients. This means when running a pipeline, it depends on e.g. environment variables to determine which client to build the product for.
One may call and compare this to a white-label product.
Because of this setup; the list of pipelines can grow large and unclear because you can't immediately see which client the pipeline is running for. You can only see the branch, but this is no anchor since this name is not unique and cannot be used to see which client it is.
To 'see' which client the pipeline is running for you need to i.e. inspect the used environment variables (in our case).
See the screenshot below for an example:
In the above screenshot, all shown pipelines were started for a different client.
I deliberately messed with the environment of some pipelines (made it fail, or used a different branch) to display the list being unclear.
The feature I'd like to request is giving a pipeline some sort of custom 'name', or 'description', which can help users more easily identify the pipeline.
This name could then be shown 'somewhere' in the list of pipelines (maybe as an extra column).
Target audience
-
Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
-
☝️ As a Product Manager it could be valuable to know which client's products are being build/updated to relay this information back to the client (if applicable). This especially correlates with the frustration: "It can be difficult to give clients a reasonable timeframe that is not off-base, since a cycle is often unpredictable."
-
-
Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
-
☝️ When (in our case) the team lead wants to manipulate a pipeline for a specific client, this can be done more easily in the list of pipelines. E.g. when changing an external variable the pipeline depends on (imagine one of the pipeline's job retrieving the name of the client from some API), the relevant pipeline can more easily be found and retried.
-
-
Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
-
☝️ Multiple developers (in our case) can more easily scan the list to see the status of pipeline for a specific client. This helps in discovering who needs to start what.
-
Further details
In the end this feature is about making the list of pipelines more convenient to use in—arguably a small number of use cases. Implementing the feature can, however, only add a win-win situation here I'd reckon.
This because you should not be required to name your pipeline, but if needed you can utilise the feature.
To support the above; I'd like to make the name more of a 'description' rather than using it to uniquely identify the pipeline. I think the ID—which pipelines already have already serve this purpose.
Proposal
Keep the scope of this proposal limited to titles since the pipeline index page cannot handle extra content at the moment
I'd like to propose using the .gitlab-cy.yml
to set the name of a pipeline, using a field named name
(or run_name
if the just 'name' would be too ambiguous).
The default could be set as an environment variable, using a combination of information already available, and changed either from the .gitlab-cy.yml
or by a setting in the pipeline settings, e.g. $CI_PIPELINE_ID: $CI_COMMIT_TITLE ($CI_COMMIT_SHA)
.
Alternatively the default could also just be 'empty', which would result in the name not being displayed in the list.
To view the name my proposal would be to add it in the cells below the Pipeline column (which is now showing the number of the pipeline and who it was started by). Ideally it would then show the name and the number of the pipeline as popup when hovering of the name (or both at the same time if this would nicely fit).
Longer names could then be truncated and shown as full when hovering over them.
Permissions and Security
Everyone with sufficient permissions to create the pipeline should also be able to name it.
Security-wise this shouldn't have an impact, albeit the name could have character restrictions (but I'm not sure what GitLab's API can support and whatnot).
Documentation
What does success look like, and how can we measure that?
Success can be defined as being able to name pipelines and see that same name back in the list of pipelines (and when the pipeline itself or any of its jobs).
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.