Pipelines
Pipelines are a top-level view, reached with Tab. The table shows the pipelines for whatever scope you browsed to: one project, a group and every subgroup under it, or every pipeline you triggered across the instance.
What you see
The columns are project, ref, pipeline number, status, duration, who triggered it, the trigger source, and when it last changed. Coverage, queued duration and failure reason appear as the terminal gets wider. Columns drop by priority as it narrows, under the same rules as every other table.
Statuses
Fifteen states. Each one has a glyph, a colour and a word, so meaning never rests on colour alone.
Thirteen of those are GitLab's. The last two are labdash's: a merge request with no pipeline, and a job that failed with allow_failure: true, which renders as a warning rather than an error.
A glyph repeats where the word separates the two states. Every glyph is one cell and every ASCII fallback is one character, so a screen rendered in either mode has identical column boundaries. No patched font is needed for any of them.
The preview pane
Selecting a pipeline shows its jobs grouped by stage, with per-job status, duration and allow-failure marking. Failed jobs carry their failure reason.
script_failure is the code or the test. runner_system_failure is the infrastructure. job_execution_timeout is neither. The three read differently on screen, so a runner capacity problem and a flaky test suite do not look alike.
Below the job list sits the failure summary: the first failing job and the lines around its error.
What you can do
| Key | Action | Key | Action |
|---|---|---|---|
| R | retry the pipeline | L | logs of the first failing job |
| x | cancel a running pipeline | m | play a manual job |
| o | open in the browser | w | watch it |
| Y | copy the URL | D | stage graph |
| V | the variables it ran with | Ctrl+N | run a new pipeline |
| S | scheduled pipelines | Enter | jobs by stage in the preview |
Destructive actions confirm inline in the footer, with the action named in full:
The confirm draws in the footer rather than as an overlay, so navigation still works underneath it.
Scope
Your own failing pipelines are on Home. For anything wider, browse to a scope and filter it:
Scope comes from the same browse tree that scopes merge requests, and it survives switching between the two views.
Pipeline kinds
GitLab creates several kinds of pipeline for one commit. labdash labels branch pipelines, merged-result pipelines and merge-train pipelines separately in the row rather than blending them into one list.
Child and parent pipelines are reachable from the preview pane, so a multi-project pipeline is navigated downstream and upstream in place.
The stage graph
D draws the pipeline as its dependency graph: stages as columns, jobs as rows, and lines for the needs: relationships between them. A wide graph scrolls sideways.
The job list in the preview answers "what failed". The graph answers "what was this waiting for", which is the question a pipeline that took forty minutes raises.
Scheduled pipelines
S opens the schedules for the current scope: every schedule, its cron description, when it last ran, when it runs next, who owns it, and whether it is active.
| Key | Action | Key | Action |
|---|---|---|---|
| Enter | the runs this schedule produced | a | activate or deactivate it |
| Ctrl+N | run it now, without waiting | o | edit it in the browser |
This is the screen that answers "why did nightly not run". Filtering the pipelines table to source:schedule shows the runs that happened, and a schedule that was switched off six weeks ago produces no rows at all, so it cannot show you the one you are looking for. Next-run times use your configured timezone.
Turning a schedule off is how a nightly build silently stops, so a names the schedule and its cadence before it deactivates one. Turning it back on needs no confirmation.