Job Management

Interactive TUI#

Launch the interactive TUI with glci (no subcommand):

• Browse Pipeline – view your CI config as a navigable graph
• Run Pipeline – start execution with live status updates
• Pipeline history – drill into previous runs, view job logs

Navigation: arrow keys/hjkl to move, Enter to drill in, Esc to go back, ? for help.

Viewing logs#

glci log                    # all logs from latest pipeline
glci log 5                  # all logs from pipeline #5
glci log 5 build-job        # log for a specific job

When a job is still running, glci log streams from the daemon in real time. Once the job completes, it reads from the stored log on disk. Press Ctrl+C to stop streaming.

Stopping pipelines#

glci stop                    # stop active pipeline for current project
glci stop 5                  # stop pipeline #5
glci stop 5 --job build      # stop specific job in pipeline #5

If the daemon no longer tracks the pipeline (e.g., after a daemon restart), glci stop <id> automatically falls back to force-removing leftover Docker containers and the pipeline network, then marks the pipeline as canceled in history.

When stopping a pipeline that has active child pipelines (from trigger: include:), all child jobs are automatically canceled first, ensuring clean shutdown across the entire pipeline hierarchy.

Retrying failed jobs#

Retry creates a new pipeline that re-runs only the failed jobs, reusing artifacts from the original run:

glci retry                  # retry all failed jobs from latest
glci retry 5                # retry all failed from pipeline #5
glci retry --job build      # retry only the "build" job

The retry command verifies that the specified job actually failed before starting.

Listing jobs#

glci jobs parses the CI config and lists all jobs that would run after rules evaluation:

glci jobs                   # list all jobs with stage, when, and needs
glci jobs --stage build     # filter by stage
glci jobs --json            # machine-readable JSON output
glci jobs --context tag=v1  # see jobs for a tag context
glci jobs -p quick          # see jobs for a pipeline preset

Active pipelines#

glci ps                  # show active pipelines and containers
glci ps --containers     # show only Docker containers (alias: -c)

Pipeline history#

glci history                 # list recent pipelines
glci history --limit 5
glci history show 3          # show pipeline details with job list
glci history clean           # delete all
glci history clean --keep 5  # keep last 5

Linting#

Validate CI configuration without running it:

glci lint                   # report job/stage count on success
glci lint --quiet           # exit code only, no output on success (alias: -q)
glci lint -f custom.yml     # lint a specific file

Exit codes: 0 for valid, non-zero for parse errors or structural issues (e.g., undefined stages, circular needs).

Named runner dispatch#

When named runners are configured, jobs are automatically dispatched to the matching runner based on their CI tags:

# .glciconfig.toml
[runners.gpu]
config_template = """
[[runners]]
  [runners.docker]
    gpus = "all"
"""

# .gitlab-ci.yml
train-model:
  tags: [gpu]
  script: python train.py

The train-model job routes to the gpu runner. Jobs without matching tags run on the default shared runner. First tag match wins when a job has multiple tags.

Health checks#

glci doctor                 # check Docker, daemon, token, CI config, git

Runs five checks and reports pass/fail/warning for each:

1. Docker – verifies Docker is reachable and reports server version
2. Daemon – checks if the glci daemon is running and reports PID
3. GitLab token – verifies a token is configured
4. CI config – parses the pipeline and reports job/stage count
5. Git repository – confirms the current directory is a git repo with branch and commit