glab ci: Trigger and Watch GitLab Pipelines

By Kaveh Alemi·Latchkey

glab ci drives GitLab pipelines: run starts one, status shows the current pipeline, and trace streams a job log.

The glab ci subcommand group is how you trigger and inspect GitLab CI/CD without the web UI, useful for chaining a downstream pipeline or gating on a status.

What it does

glab ci groups pipeline operations. run creates a new pipeline for a branch, status shows the latest pipeline for the current ref, trace streams a running job log, and view opens an interactive pipeline browser.

Common usage

# trigger a pipeline on a branch with a variable
glab ci run --branch main --variables DEPLOY_ENV:staging
# show the current pipeline status for this ref
glab ci status
# stream the log of a job
glab ci trace --branch main

Options

In CI

glab ci view is interactive (a TUI) and will hang a headless job; use glab ci status or glab ci list in scripts instead. Triggering a child pipeline with glab ci run needs a token with api scope on the target project.

Common errors in CI

"authentication required" means no valid GITLAB_TOKEN. "404 Not Found" from glab ci status usually means the ref has no pipeline yet or the token cannot see the project. "You cannot create a pipeline for this project" (403) means the token lacks permission to run pipelines. A frozen job is usually glab ci view waiting for a terminal.

Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached

Frequently asked questions

Related guides

References

• GitHub Actions documentation