0d31560e38
jobq.md's "Watching it happen" section ended by promising that a step which
isn't needed "shows as `·` rather than dropping out of the tree entirely, so
the same kind of operation keeps a recognizable shape run to run".
In that view it does drop out. `JobqGraph.tsx:94` sets
`DEFAULT_HIDDEN_STATES = {Done, Skipped}` under the comment 'Product call:
"default selection filters out skipped and done"', `:299` seeds the selection as
everything except those, and `:271` puts the selection in the query string — so
the hidden states are never fetched, not merely styled out. That component is
what renders both surfaces the page names, and neither passes an override.
The claim is true of the data and false of the screen, in a section about what
is on the screen. Keeping both: the node stays in the graph, and the default
filter is named, along with the part that would otherwise surprise someone
debugging it — the selection is a request parameter.
Closes #4223.
56 lines
3 KiB
Markdown
56 lines
3 KiB
Markdown
# The job queue, for operators
|
|
|
|
Every container operation — rebuild, first-spawn, a config-PR deploy,
|
|
power changes — runs through one shared job queue. This page explains
|
|
what the job queue _is_, as a general idea, independent of what any one
|
|
subsystem uses it for. For the hive-c0re-specific step catalogue and the
|
|
engineering internals (scheduler, leases, resource windows) see
|
|
[`coordinator.md`](coordinator.md) instead.
|
|
|
|
## What the job queue is, in the abstract
|
|
|
|
"jobq" is a generic engine for running many interdependent jobs under
|
|
limited concurrency — it has no idea what a "container" or a "rebuild" is.
|
|
Two ideas are all there is to it:
|
|
|
|
- **A job is a small graph of steps**, not one opaque blob. Steps can
|
|
depend on each other (this step only starts once that one finishes), so
|
|
a big operation is really a short, ordered sequence — not a single
|
|
black box that's either "done" or "not done."
|
|
- **A step can need a shared resource**, which only so many steps can hold
|
|
at once (a "slot"). If every currently running step already holds the
|
|
slots it needs, a new step that wants the same one waits its turn —
|
|
that's the whole reason things queue instead of all firing at once.
|
|
|
|
The engine's whole job is: whenever a step's ordering and resource needs
|
|
are both satisfied, run it. It has no opinion on what the steps _do_ —
|
|
that's supplied by whoever builds the graph. hive-c0re is the one thing
|
|
building graphs on it today, but nothing about the engine is specific to
|
|
containers or rebuilds; there's nothing stopping another subsystem from
|
|
using the same engine for its own unrelated queue.
|
|
|
|
## Watching it happen
|
|
|
|
Each **row** you see in a queue view (the **BU1LDS** page's R3BU1LD QU3U3
|
|
— see [`web-ui/dashboard.md`](../web-ui/dashboard.md) — and swarm-ui's
|
|
`/jobs` page both render the same underlying graph) is one job; the rows
|
|
nested under it are that job's steps, in order (occasionally a couple run
|
|
side by side). A step shows one of:
|
|
|
|
| Glyph | Meaning |
|
|
| ----- | ------------------------------------------------------- |
|
|
| `⏸` | queued, waiting its turn |
|
|
| `▶` | running |
|
|
| `◐` | its own work is done, waiting on a step nested under it |
|
|
| `✔` | finished successfully |
|
|
| `✖` | failed |
|
|
| `⊘` | cancelled |
|
|
| `·` | skipped (not needed for this run) |
|
|
|
|
A step that isn't needed for a given run stays in the graph as `·` rather
|
|
than being absent from it, so the same kind of operation keeps a
|
|
recognizable shape run to run, whichever steps it actually needed.
|
|
|
|
⚠️ **The view hides `✔` and `·` by default**, so that full shape isn't what
|
|
you see first — tick them back on in the state filter. The selection is
|
|
part of the request, not a display toggle: hidden states are never fetched.
|