Add custom labels to CICD pipelines

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Close this issue

Status Update (22nd March 2026)

We've discussed internally on couple of different approaches on setting the labels

A new workflow:labels keyword in .gitlab-ci.yml, allowing teams to set conditional labels at the pipeline level
Extend the workflow:name to accept up to 5 values

Howevere, regardless of the setting approach the main blocker is a technical dependency. Delivering meaningful label filtering requires ElasticSearch indexing infrastructure that is not yet scheduled - #505379. We don't want to ship labels without filtering, as that would only partially solve the problem.

We'll share an update once the underlying infrastructure work gets scheduled.

Problem to Solve

The core problem is that it is very difficult to organize and identify pipelines at a glance. This manifests in several specific pain points:

Identification problems — When multiple pipelines run against the same branch (e.g., deploy to production, staging, canary, dry-run), they are visually indistinguishable in the pipeline list. Users must click into each pipeline and inspect job logs to understand what it actually does.

Scheduled pipeline confusion — Teams running multiple scheduled pipelines (e.g., Renovate, regression tests, security scans, code scanning) on the same branch can't tell them apart without drilling in. They all look identical in the list view.

From @Taucher2003 - In my instance, I have a Tasks Projects which serves as Task Runner via Pipeline Schedules (Things like Renovate, GitLab Triage, ...). As they are scheduled, they just run always on master with the latest configuration. However, there is no option to see, which pipeline belongs to which task (they are different schedules) as all Pipelines have the same amount of stages and you need to view the jobs in the second stage to see, which Task was run.

Variable injection opacity — When teams trigger many pipelines in quick succession with different injected variables (e.g., 10+ pipelines for different config parameters on the same commit), there's no way to later recover which variables were used in which run without going into each one individually.

The current workflow requires the users to run multiple pipelines for the same commit in order to inject different configuration parameters. They might be required to trigger ~10 pipelines or more in a short time. It is very difficult then to go back and retrieve what configuration was injected on which pipeline. Having the possibility of configuring custom tags to pipelines (and having a search bar filter to filter pipelines based on that) would really help our users productivity.

Monorepo visibility — In large monorepos, pipelines triggered by different sub-projects or stakeholder groups are completely undifferentiated, creating significant friction.

Cross-project deployment troubleshooting — When a deployment pipeline lives in a separate downstream/infrastructure project for compliance reasons, developers in the originating project have no visibility into why a pipeline failed (e.g., deploy freeze, code freeze) without access to the downstream project.

Especially for multi-project pipelines, like when a developer kicks off a pipeline and the deployment really happens in another project. Seeing something did not deploy because of code freeze or some other reasons makes for easier troubleshooting.

Gitlab.com uses CICD for our deployments. A single pipeline may be a deploy to production, staging, canary or a dry-run deployment for testing. It would be nice to have the ability to annotate the pipelines especially when there multiple deploys going in parallel to different stages:

Who's it for?

Developers

Workaround

workflow:name with dynamic variables — Using GitLab's existing pipeline naming feature with CI variables to embed distinguishing info into the pipeline title:

Limitation of the workaround

There is no filtering by pipeline name on list view - #376097
workflow:name is a single string - so cannot represent multiple attributes
There is no way to capture the information that becomes known during the pipeline run

Proposal [TBD]

if we could add labels in gitlab-ci.yml that would appear on the pipeline overview, something like this:

.staging:
  ...
  labels:
    - staging
staging-api:
  extends: .staging
  stage: staging-api
staging-web:
  extends: .staging
  stage: staging-web

And then all labels for the jobs in a pipeline execution would display on the overview.

Acceptance Criteria for an MVC

A user can add a label to a pipeline in a .gitlab-ci.yml file which passes the CI Linter
The label appears on the Pipeline list page
Follow-up issues created for other interfaces this needs to be placed on / user reporting needs for pipelines.

Iteration notes

This may also be helpful in release related interfaces?
Adding label to API responses
Allow setting labels through API
Managing/reviewing/reporting for Labels at a project / group / workspace level

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.

Edited Mar 22, 2026 by 🤖 GitLab Bot 🤖