Pipelines

Use the Pipelines tab to monitor and manage GitLab pipelines.

Navigate the Pipelines tab

When more entries are available, use Load more at the end of the list. A line above the list says how many pipelines there are.

In the activity panel, Run Pipeline, the filter icon, and More actions share the title row with the source badge.

To open the Pipelines tab click DevOps > Pipelines.

Pipeline runs are listed chronologically and display the following information.

• Status icon: Indicates if a pipeline run is in progress, completed, queued, or skipped.
• Title and pipeline number: The name of the pipeline, or Pipeline when it has no name, and the pipeline number.
• Ref: The branch or tag that the pipeline ran on.
• Source: What started the pipeline run, for example a push or a schedule.
• Commit: The commit that the pipeline ran on. The activity panel does not show it.
• Timestamp: How long ago the pipeline run occurred.

Click a pipeline to open its detail tab.

To open a pipeline in a separate tab, right-click the pipeline and click Open in New Tab.

To open the page on GitLab, click the source badge at the right of the tab header, then click Open on GitLab. A detail tab opens its pipeline; the Pipelines tab opens the project’s pipeline list.

Pipeline detail tab

A card at the top of the detail tab shows the pipeline status, Cancel, Retry, and these facts:

• Ref: The branch or tag that the pipeline ran on.
• Commit: The commit that the pipeline ran on.
• Started: When the pipeline started.
• Duration: How long the pipeline ran.
• Variables: The variables that someone entered when they started the pipeline, not every CI/CD variable that the jobs use. GitLab shows a value only if the project setting Display pipeline variables is on and your role permits it; otherwise the value shows Hidden. Variables does not appear when the pipeline was started without variables, or when your GitLab version cannot report them. GitLab does not report pipeline inputs.

Click More details to show Source (what started the pipeline), Trigger author (who started it), and Updated. Click Fewer details to hide them.

Cancel stops a running pipeline. Retry runs the failed and canceled jobs again. An unavailable button is dimmed. Point to it to see the reason, for example Pipeline has finished or You do not have permission to retry this pipeline.

Jobs

Jobs are grouped under their stage names. Each job is a card that shows its status, name, duration, and job action icons. allowed to fail appears next to a failed job that is allowed to fail.

• Run Job starts a manual job. Only manual jobs have this icon.
• Retry Job runs a finished job again. The new job replaces the old one in the list.
• Cancel Job stops a job that is pending or running.

An unavailable action is dimmed. Point to it to see the reason, for example Job has not finished or You do not have permission to run this job.

Click a job card, or its chevron, to open it. The open card shows the job status, stage, start time, and duration, the job actions as labeled buttons, and the job log. One card is open at a time. To close the open card, click it again or click More actions > Collapse All.

Pipelines from a merge request

A merge request’s pipeline badge and its Pipeline jobs view open this tab. A job that you click there opens here already open. A merge request from a fork can run its pipeline in the fork’s project. The tab then shows that pipeline from the fork and adds a Project fact with the fork’s name. GitLab decides which pipeline and job actions your account can use in the fork; an unavailable action is dimmed with GitLab’s reason. If your account cannot read the fork, the tab says so and offers Open on GitLab.

Filter pipelines

Click the Show filters icon to open the filter panel. GitLab applies each filter to all of the project’s pipelines, not only the loaded ones.

• Status: Running, Pending, Success, Failed, Canceled, Skipped, or Manual.
• Branch or tag: Type the full name. The name must match exactly, including case.
• Source: What started the pipeline, for example Push, Merge Request, Scheduled, or Web. The list also shows sources that your GitLab adds, such as Duo Workflow, when a loaded pipeline has one.
• Trigger author: Type the GitLab username of the person who started the pipeline. Case does not matter.

Press Ctrl+F (Cmd+F on macOS) to open the panel and focus Branch or tag. When the panel is too narrow for the icon, click More actions > Show Filters.

The line above the list says how many pipelines there are: N pipelines with no filter, or N matches with one. When no pipeline matches, the list says No results. Each filter that is set shows as a chip above the count, for example Source: Web. Click a chip to open the panel at that filter: a list opens, and a text field gets the cursor. Click its x to remove the filter. To remove all of them, click Clear filters at the end of the count line. In a narrow panel the button says Clear. The filters stay while Zide is open.

Run a pipeline

To run a pipeline, complete the following steps.

1. In the Pipelines tab, click Run Pipeline.
2. In the Run Pipeline dialog, the Branch or tag field shows the current branch. To run on a different branch or tag, enter or select it.
3. If the pipeline has inputs, set them under Inputs. A red asterisk (*) marks an input that needs a value.
4. Optional: Under Variables, change the prefilled variables. To add a CI/CD variable that the configuration does not list, enter a key and a value in the Key and Value fields. When the configuration has prefilled variables, these fields are under Other variables. Click Add Variable to add a row.
5. Click Run.

The field lists the repository’s branches and tags. Type to search, or click the list button or press Down to show the list. If a branch and a tag have the same name, choose one from the list. If the field is empty or the repository does not have the name, a message shows below the field and Run is unavailable. Point to Run to see the reason.

Zide reads the inputs and variables from the pipeline configuration on the branch or tag, including the files that it includes. It reads them again when you change the branch or tag. While Zide reads, the dialog says Reading the pipeline configuration… and Run is unavailable.

Inputs shows the inputs from spec:inputs. Each input shows its default value, with its description below it:

• An input with options is a list of its options.
• A boolean input is a checkbox.
• A number input is a text field, marked (number).
• An array input is a text box, marked (JSON array). Enter a JSON array, for example ["web", "worker"].
• A string input is a text field. If the input has a regex, the value must match it.

Variables shows the prefilled variables. These are the configuration’s variables that have a description, as on GitLab’s Run pipeline page. A variable with options is a list. Other configuration variables keep their values and are not shown.

Zide sends an input or a prefilled variable only when its value differs from the configuration. If you leave an input empty and it does not need a value, GitLab uses its default. If you clear a prefilled variable, Zide sends it with an empty value. When the fields load again, a value that you changed stays if the input or variable has the same name. A list keeps your choice only if it still has that value.

Run is unavailable until each required input has a value and each value is valid. Point to Run to see the first problem. If you leave a field with a problem, a message shows below it. A key under Other variables cannot repeat a variable above it or another row.

If an input needs a value and has no default, GitLab does not list the prefilled variables. Variables then shows only the Key and Value fields. GitLab’s Run pipeline page shows the same.

GitLab accepts pipeline inputs from Zide in GitLab 18.1 and later. Zide sends inputs only when it can confirm the GitLab version. With an earlier version, or when Zide cannot get the version, the dialog has no Inputs group and says that the run uses each input’s default. If an input needs a value and has no default, the dialog says that GitLab will refuse the run.

If Zide cannot read the configuration, for example because it is not valid YAML, the dialog shows GitLab’s reason, and Variables shows only the Key and Value fields. Run stays available, and GitLab checks the run. If GitLab does not start the pipeline, the dialog shows the reason.

GitLab sends inputs to the pipeline’s spec:inputs, and variables as CI/CD variables. The project must allow pipeline variables for your role. Zide does not write input or variable values to the App Console.

Zide Assist can also list the inputs and prefilled variables of a branch or tag, and run a pipeline with inputs and variables. When Zide Assist can read the configuration, it checks the inputs before it starts the run. If it cannot read the configuration, it runs a pipeline only without inputs.

Assist with This

Right-click a pipeline, or its detail tab, and point to Assist with This.

Under Zide Assist, click Add to Conversation to attach the pipeline to a Zide Assist tab. You can also drag the pipeline into a Zide Assist tab. For more information, see Attach items to a message.

Under Ask Zide, click Open Ask Zide. Zide opens the pipeline in its detail tab with an Ask Zide panel beside it. In the panel, click Summarize Outcome or Explain Failure. Explain Failure is unavailable when the pipeline has no failed job. When a job failed, Explain Failure is first. Ask Zide does not run or cancel the pipeline. See Ask Zide beside a tab.

Activity indicator

The activity icon is blue while a run is running or queued, amber when waiting for user action, and red for a failure on the current branch. Successful runs leave the icon neutral.

The indicator follows the newest commit with pipeline runs on the current branch. A newer commit starts with its own results. By default, a failure stays red while that commit retries, until it succeeds. To clear failure indicators when viewed, turn off More actions > Failure indicator > Keep failure indicator after viewing. This preference is shared by Actions and Pipelines across projects and persists across restarts.

Run and job status icons use blue for running, queued, or preparing work, amber for work waiting for user action, red for failures, and green for success. Stopped, cancelled, skipped, and unknown results are neutral.