#Job logs

▍job-trace120×32

job-traceA full-screen job trace. The header names the project, the pipeline, the job, its failed status, its duration, the runner that took it, a follow indicator and the line count. Most of the log is folded into section headings with their durations; one section is open, showing numbered lines around a failed test assertion. The footer carries an active search and the fold, follow, copy and retry keys.

#What you see

Full screen. The trace viewer is the one screen that takes the whole frame from the dashboard, because a log needs every column it can get.

Folded by default. GitLab emits section markers in its traces and labdash folds on them, so a 40,000-line log opens as about twelve headings with their durations. z folds and unfolds one, Z does all of them.

Line numbers, always on. The header carries the current line and the total, so a line you paste into an issue has a number attached to it.

ANSI colour, contained. GitLab traces carry real ANSI escapes. labdash renders them and stops them from repainting the frame around the log.

follow as a visible state. It shows in the header. Scrolling up releases it and w re-engages it, so the view is never moving or still for a reason you cannot see.

#Opening a log

L from a failed pipeline row lands on the first failing job's log, already scrolled to the error. It does not open at line 1, and it does not stop at a job list first.

L works the same way from a merge request row, where it opens the failing job of that merge request's head pipeline.

#What you can do

Key	Action	Key	Action
w	follow a running job	/	search
z Z	fold one section, fold all	n N	next and previous match
y	copy to the clipboard	g G	first line, last line
S	save to a file	R	retry this job
Esc	back to the pipeline	Ctrl+d Ctrl+u	page down and up

y works over SSH and inside tmux through OSC 52, with no clipboard helper installed. S writes the raw trace to a file, which is what a bug report wants.

#Live follow

Following a running job polls the trace incrementally and appends the new lines. Polling stops when the job reaches a terminal state, so a finished job leaves no poller behind it.

#The trace source

GitLab's GraphQL CiJobTrace type exposes one field, htmlSummary, and it is a truncated tail. labdash reads the full log from REST instead, GET /projects/:id/jobs/:job_id/trace, so every line the runner produced is there to fold, search, copy and save.

#The job list

The pipeline preview lists every job in the selected pipeline, ordered by stage, with status, duration, allow-failure marking, runner and tags. From there:

Key	Action	Key	Action
R	retry this job only	m	play a manual job, such as a deploy gate
x	cancel this job, or unschedule a delayed one	L	its full trace

Each job row also names the runner that took it, which is the first thing to check when a job is slow.

#Artifacts

A job that produced artifacts lists them in the preview with their sizes. Downloading one writes it to disk and reports the path; a large archive streams rather than being held in memory, so a two-gigabyte artifact costs disk and not RAM.

This is the other reason to open a job that passed: the report it generated is attached to it.