glab-pipeline

View a running pipeline on the current branch

$ glab pipeline status

$ glab pipeline status --branch [branch_name]

$ glab pipeline list

$ glab pipeline run

$ glab pipeline run --branch [branch_name]

glab pipeline <command> [flags]

Common commands:
glab pipeline ci [flags]
glab pipeline list [flags]
glab pipeline view <pipeline-id> [flags]
glab pipeline retry <pipeline-id> [flags]
glab pipeline cancel <pipeline-id> [flags]
glab pipeline delete <pipeline-id> [flags]

ci
    Trigger a custom CI job with specific variables and a Git ref (branch or tag).

list
    List all pipelines for a project, with options to filter by branch or status.

view
    Display detailed information about a specific pipeline by its ID, including its jobs and their statuses.

retry
    Retry a previously failed or canceled pipeline by its ID.

cancel
    Cancel a currently running or pending pipeline by its ID.

delete
    Delete a specific pipeline by its ID. This action is irreversible and should be used with caution.

-R, --repo
    Specify the GitLab repository by its 'owner/repo' path. This overrides the repository inferred from the current working directory.

-P, --project
    Specify the GitLab project by its numerical ID. This is useful when not in a Git repository or for ambiguous project names.

--host
    Specify the GitLab host (e.g., gitlab.com or your self-hosted instance). This overrides any configured default host.

--token
    Provide a GitLab personal access token or OAuth token directly for authentication. This overrides any token configured via glab auth login.

--all
    (Used with list command) List all pipelines, not just the default paginated number of results. Useful for comprehensive overviews.

--branch
    (Used with list or ci command) Filter pipelines by a specific branch name, or specify the branch for a new CI job trigger.

--status
    (Used with list command) Filter pipelines by their current status, such as success, failed, running, pending, etc.

--ref
    (Used with ci command) Specify a specific Git reference (branch name or tag) against which the CI job should be executed.

--variables
    (Used with ci command) Pass custom CI/CD variables as a comma-separated list of key=value pairs to the triggered pipeline.

The glab-pipeline command is a powerful subcommand of the glab official GitLab CLI tool, designed to streamline interaction with GitLab's Continuous Integration/Continuous Delivery (CI/CD) pipelines directly from your terminal. It allows users to programmatically manage, monitor, and troubleshoot CI/CD workflows without needing to navigate the GitLab web interface. This command provides functionalities to list all pipelines for a project, view detailed information about a specific pipeline (including its jobs and status), retry failed or canceled pipelines, cancel running pipelines, and delete old or unnecessary pipelines. By integrating glab-pipeline into development workflows, scripts, or automation tools, developers and operations teams can significantly improve efficiency, enforce CI/CD best practices, and facilitate rapid iteration on software delivery. It leverages the GitLab API, offering a consistent and authenticated way to control your project's build and deployment processes.

Requires the glab CLI tool to be installed and accessible in your system's PATH. Proper authentication with GitLab is essential; glab-pipeline operates under the permissions of the authenticated user or token. Insufficient permissions will result in errors. Network connectivity to the specified GitLab host is required for all operations. While powerful for management, understanding complex CI/CD logic might still require reviewing the .gitlab-ci.yml configuration file or the GitLab web UI for full context.

To use glab-pipeline, you must first authenticate with your GitLab instance. This is typically done via glab auth login, which guides you through setting up a Personal Access Token or OAuth. Once authenticated, glab stores your credentials, allowing subsequent commands to operate without manual authentication. You can also configure the default GitLab host and project.

glab-pipeline commands usually infer the GitLab project from your current working directory (if it's a Git repository connected to GitLab). If not, or if you wish to target a different project, you must explicitly specify the project using the --repo or --project flags.

Many glab pipeline commands, especially list and view, support various output formats (e.g., JSON, YAML, or custom templates) using global glab flags like --json, --yaml, or --template. This feature is highly useful for scripting and integration with other automation tools.

The glab CLI tool, including its pipeline subcommand, emerged as the official command-line interface for GitLab, inspired by the success of similar tools like GitHub's gh CLI. Its development aimed to provide a first-class, intuitive, and efficient way for developers and DevOps engineers to interact with GitLab from their terminal, reducing context switching and enabling advanced automation. The pipeline subcommand, in particular, was a critical addition, reflecting GitLab's strong emphasis on CI/CD as a core feature. Its evolution tracks GitLab's own CI/CD capabilities, offering programmatic control over a wide array of pipeline operations since its inception.

glab(1): The main GitLab CLI tool, of which `pipeline` is a subcommand., git(1): The distributed version control system, fundamental to managing project repositories on GitLab., curl(1): A command-line tool for transferring data with URLs, often used for direct GitLab API interaction when `glab` functionality is insufficient., gitlab-ci.yml: The configuration file for GitLab CI/CD pipelines, defining the jobs and stages managed by `glab pipeline` (conceptual relation, not a command).