cli

GLab

GLab is an open source GitLab CLI tool. It brings GitLab to your terminal, next to where you are already working with git and your code, without switching between windows and browser tabs. While it's powerful for issues and merge requests, glab does even more:

• View, manage, and retry CI/CD pipelines directly from your CLI.
• Create changelogs.
• Create and manage releases.
• Ask GitLab Duo Chat (Classic) questions about Git.
• Manage GitLab agents for Kubernetes.

glab is available for repositories hosted on GitLab.com, GitLab Dedicated, and GitLab Self-Managed. It supports multiple authenticated GitLab instances, and automatically detects the authenticated hostname from the remotes available in your working Git directory.

Table of contents

• Requirements
• Usage
  • Core commands
  • GitLab Duo for the CLI
• Demo
• Documentation
• Installation
  • Homebrew
  • Other installation methods
  • Building from source
    • Prerequisites for building from source
• Authentication
• Configuration
  • Configure glab to use your GitLab Self-Managed or GitLab Dedicated instance
  • Configure glab to use mTLS certificates
  • Configure glab to use self-signed certificates
• Environment variables
  • GitLab access variables
  • glab configuration variables
  • Other variables
  • Token and environment variable precedence
  • Debugging
• Troubleshooting
• Issues
• Security
• Contributing
  • Versioning
  • Classify version changes
  • Compatibility
• Inspiration

Requirements

glab officially supports GitLab versions 16.0 and later. Certain commands might require more recent versions. While many commands might work properly in GitLab versions 15.x and earlier, no support is provided for these versions.

Usage

To get started with glab:

1. Follow the installation instructions appropriate for your operating system.
2. Authenticate into your instance of GitLab.
3. Optional. Configure glab further to meet your needs:
   • 1Password users can configure it to authenticate to glab.
   • Set any needed global, per-project, or per-host configuration.
   • Set any needed environment variables.

You're ready!

Core commands

Run glab --help to view a list of core commands in your terminal.

• glab alias: Create, list, and delete aliases.
• glab api: Make authenticated requests to the GitLab API.
• glab auth: Manage the authentication state of the CLI.
• glab changelog: Interact with the changelog API.
• glab check-update: Check for updates to the CLI.
• glab ci: Work with GitLab CI/CD pipelines and jobs.
• glab cluster: Manage GitLab agents for Kubernetes and their clusters.
• glab completion: Generate shell completion scripts.
• glab config: Set and get CLI settings.
• glab container-registry: Work with GitLab container registries.
• glab deploy-key: Manage deploy keys.
• glab duo: Generate terminal commands from natural language.
• glab gpg-key: Manage GPG keys registered with your GitLab account.
• glab incident: Work with GitLab incidents.
• glab issue: Work with GitLab issues.
• glab iteration: Retrieve iteration information.
• glab job: Work with GitLab CI/CD jobs.
• glab label: Manage labels for your project.
• glab mcp: Work with a Model Context Protocol (MCP) server. (EXPERIMENTAL)
• glab milestone: Manage group or project milestones.
• glab mr: Create, view, and manage merge requests.
• glab opentofu: Work with the OpenTofu or Terraform integration.
• glab release: Manage GitLab releases.
• glab repo: Work with GitLab repositories and projects.
• glab schedule: Work with GitLab CI/CD schedules.
• glab securefile: Manage secure files for a project.
• glab snippet: Create, view and manage snippets.
• glab ssh-key: Manage SSH keys registered with your GitLab account.
• glab stack: Create, manage, and work with stacked diffs.
• glab token: Manage personal, project, or group tokens.
• glab user: Interact with a GitLab user account.
• glab variable: Manage variables for a GitLab project or group.
• glab version: Show version information for the CLI.

Commands follow this pattern:

glab <command> <subcommand> [flags]

Many core commands also have sub-commands. Some examples:

• List merge requests assigned to you: glab mr list --assignee=@me
• List review requests for you: glab mr list --reviewer=@me
• Approve a merge request: glab mr approve 235
• Create an issue, and add milestone, title, and label: glab issue create -m release-2.0.0 -t "My title here" --label important

GitLab Duo for the CLI

The GitLab CLI also includes support for using the GitLab Duo Agent Platform directly in your terminal.

Use glab duo cli to ask GitLab Duo questions about your codebase and to autonomously perform actions on your behalf.

For more information, see GitLab Duo CLI.

Demo

Documentation

Read the documentation for usage instructions or check out glab help.

Installation

Download a binary suitable for your OS at the releases page. Other installation methods depend on your operating system.

Homebrew

Homebrew is the officially supported package manager for macOS, Linux, and Windows (through Windows Subsystem for Linux)

• Homebrew
  • Install with: brew install glab
  • Update with: brew upgrade glab

Other installation methods

Other options to install the GitLab CLI that may not be officially supported or are maintained by the community are also available.

Building from source

If a supported binary for your OS is not found at the releases page, you can build from source:

Prerequisites for building from source

• make
• Go version as defined by main/go.mod

To build from source:

1. Run go version to verify that you have the minimum required Go version. If Go is not installed, see Download and install.
2. Clone the repository: git clone https://gitlab.com/gitlab-org/cli.git
3. Build the binary: make build
4. Install glab in $GOPATH/bin: make install
5. Optional. If $GOPATH/bin or $GOBIN is not in your $PATH, run export PATH=$PWD/bin:$PATH.
6. Confirm the installation: glab version

Authentication

To authenticate glab with OAuth, a personal access token, or a CI job token, see Authenticate with GitLab.

Configuration

By default, glab follows the XDG Base Directory Spec, which means it searches for configuration files in multiple locations with proper precedence.

Configuration Levels

Configure glab at different levels: system-wide, globally (per-user), locally (per-repository), or per host:

• System-wide (for all users): Place configuration at /etc/xdg/glab-cli/config.yml (or $XDG_CONFIG_DIRS/glab-cli/config.yml).
  • Useful for Linux distributions and system administrators to provide default configurations.
  • User configurations will override system-wide settings.
• Globally (per-user): run glab config set --global editor vim.
  • The global configuration file is available at ~/.config/glab-cli/config.yml (or $XDG_CONFIG_HOME/glab-cli/config.yml).
  • To override this location, set the GLAB_CONFIG_DIR environment variable.
• The current repository: run glab config set editor vim in any folder in a Git repository.
  • The local configuration file is available at .git/glab-cli/config.yml in the current working Git directory.
• Per host: run glab config set editor vim --host gitlab.example.org, changing the --host parameter to meet your needs.
  • Per-host configuration info is always stored in the global configuration file, with or without the global flag.

Configuration Search Order

When glab looks for configuration files, it searches in this order (highest priority first):

1. $GLAB_CONFIG_DIR/config.yml (if GLAB_CONFIG_DIR is set)
2. ~/.config/glab-cli/config.yml (legacy location, for backward compatibility)
3. $XDG_CONFIG_HOME/glab-cli/config.yml (platform-specific XDG location)
4. $XDG_CONFIG_DIRS/glab-cli/config.yml (system-wide configs, default: /etc/xdg/glab-cli/config.yml)

The first configuration file found is used.

Configuration File Locations

For backward compatibility, glab checks ~/.config/glab-cli/config.yml first on all platforms. If no legacy config exists, glab uses platform-specific XDG Base Directory locations:

• Linux: ~/.config/glab-cli/config.yml (XDG_CONFIG_HOME)
• macOS: ~/Library/Application Support/glab-cli/config.yml (XDG_CONFIG_HOME)
• Windows: %LOCALAPPDATA%\glab-cli\config.yml (XDG_CONFIG_HOME)

Note: If you have config files in both the legacy location (~/.config/glab-cli/config.yml) and the platform-specific XDG location, glab will use the legacy location and display a warning. Consider consolidating to one location to avoid confusion.

Configure glab to use your GitLab Self-Managed or GitLab Dedicated instance

When outside a Git repository, glab uses gitlab.com by default. For glab to default to your GitLab Self-Managed or GitLab Dedicated instance when you are not in a Git repository, change the host configuration settings. Use this command, changing gitlab.example.com to the domain name of your instance:

glab config set -g host gitlab.example.com

Setting this configuration enables you to perform commands outside a Git repository while using your GitLab Self-Managed or GitLab Dedicated instance. For example:

• glab repo clone group/project
• glab issue list -R group/project

If you don't set a default domain name, you can declare one for the current command with the GITLAB_HOST environment variable, like this:

• GITLAB_HOST=gitlab.example.com glab repo clone group/project
• GITLAB_HOST=gitlab.example.com glab issue list -R group/project

When inside a Git repository glab will use that repository's GitLab host by default. For example glab issue list will list all issues of the current directory's Git repository.

Configure glab to use mTLS certificates

To use a mutual TLS (Mutual Transport Layer Security) certificate with glab, edit your global configuration file (~/.config/glab-cli/config.yml) to provide connection information:

hosts:
    git.your-domain.com:
        api_protocol: https
        api_host: git.your-domain.com
        token: xxxxxxxxxxxxxxxxxxxxxxxxx
        client_cert: /path/to/client.crt
        client_key: /path/to/client.key
        ca_cert: /path/to/ca-chain.pem

• ca_cert is optional for mTLS support if you use a publicly signed server certificate.
• token is not required if you use a different authentication method.

Configure glab to use self-signed certificates

To configure the GitLab CLI to support GitLab Self-Managed and GitLab Dedicated instances with self-signed certificates, either:

• Disable TLS verification with:

  glab config set skip_tls_verify true --host gitlab.example.com
  

• Add the path to the self signed CA:

  glab config set ca_cert /path/to/server.pem --host gitlab.example.com
  

Environment variables

GitLab access variables

glab configuration variables

Other variables

Variable deprecation

In glab version 2.0.0 and later, all glab environment variables are prefixed with GLAB_. For more information about this deprecation, see issue 7999.

Token and environment variable precedence

GLab uses tokens in this order:

1. Environment variable (GITLAB_TOKEN).
2. Configuration file ($HOME/.config/glab-cli/config.yml).

Debugging

When the GLAB_DEBUG environment variable is set to true, glab outputs more logging information, including:

• Underlying Git commands.
• Expanded aliases.
• DNS error details.

Troubleshooting

For help with common authentication issues, see Troubleshooting in the GitLab CLI documentation.

Issues

If you have an issue: report it on the issue tracker

Security

To report a security vulnerability in glab, follow the process in the security policy. Please do not open a public issue.

To learn how the project handles dependency updates and container-scanner CVE reports, see dependency management and reporting a vulnerability in CONTRIBUTING.md.

Contributing

Feel like contributing? That's awesome! We have a contributing guide and Code of conduct to help guide you.

When updating command help text or documentation, follow the GitLab CLI documentation style guide.

Versioning

This project follows the SemVer specification.

Classify version changes

• If deleting a command, changing how it behaves, or adding a new required flag, the release must use a new MAJOR revision.
• If adding a new command or optional flag, the release must use a new MINOR revision.
• If fixing a bug, the release must use a new PATCH revision.

Compatibility

We do our best to introduce breaking changes only when releasing a new MAJOR version. Unfortunately, there are situations where this is not possible, and we may introduce a breaking change in a MINOR or PATCH version. Some of situations where we may do so:

• If a security issue is discovered, and the solution requires a breaking change, we may introduce such a change to resolve the issue and protect our users.
• If a feature was not working as intended, and the bug fix requires a breaking change, the bug fix may be introduced to ensure the functionality works as intended.
• When feature behavior is overwhelmingly confusing due to a vague specification on how it should work. In such cases, we may refine the specification to remove the ambiguity, and introduce a breaking change that aligns with the refined specification. For an example of this, see merge request 1382.
• Experimental features are not guaranteed to be stable, and can be modified or removed without a breaking change.

Breaking changes are a last resort, and we try our best to only introduce them when absolutely necessary.

Inspiration

The GitLab CLI was adopted from Clement Sam in 2022 to serve as the official CLI of GitLab. Over the years the project has been inspired by both the GitHub CLI and Zaq? Wiedmann's lab.

Lab has served as the foundation for many of the GitLab CI/CD commands including ci view and ci trace.