History and filters
A job's run history is paginated and its filters are evaluated on the server — unlike the job list, and for a reason.
The Run history tab on a job's page is every run the job has ever had, newest first, with the icon for its state and its trigger, the agent, the timings and the exit status. A click opens the output.
Pagination
The history loads fifty at a time, and the next page arrives when you scroll to
the end. The tab's header carries the total — 1,284 runs, or
37 runs matching filters — and it is the count on the server, not the count
of rows loaded. The history is never truncated: after a while the
plan sweeps the text of an output, not the rows.
Filters
Four of them, composing with AND:
| Filter | What it does |
|---|---|
| From and To | The date and time the run was created, both bounds optional. The time is in your browser's zone. |
| Agent | A toggle for each of the job's agents. Two of them on means "either of these" — no run has two agents. |
| Exit code | An exact value: 1 finds runs with exit status 1, 0 the successful ones. Runs with no status (killed, never started) are found by no value at all. |
There is no filter by state here; the job list filters jobs by their latest state, and what is running right now is on the dashboard.
Why this filters on the server
The job list is fetched whole and narrowed in the browser, because it can be
fetched whole. A job's history cannot — which is why it is paginated — and a
filter over the pages already loaded would narrow only what is on screen, and
the number in the header would be lying. So every change to a filter is a new
query and a new total, and 37 runs matching filters holds for the whole
history.