glab ci: Trigger and Watch GitLab Pipelines
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 mainOptions
| Subcommand / Flag | What it does |
|---|---|
| glab ci run | Create a new pipeline |
| --branch <b> | Ref to run the pipeline on |
| --variables KEY:VALUE | Set a pipeline variable (repeatable) |
| glab ci status | Show the latest pipeline for the current ref |
| glab ci trace [<job>] | Stream a job log |
| glab ci view | Interactive pipeline/job browser |
| glab ci list | List recent pipelines |
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.