Expand description
runnerd-web: the dashboard the daemon serves on a loopback TCP port. It is a client of the daemon’s API like
runnerctl: it reads runnerd_core::api types over the daemon’s Unix socket (runnerd_core::client), renders
HTML on the server (views, chart), and keeps open pages current over SSE with Datastar (live). Writes
(pause, reseed, the config) are passed on to the same API (actions). It holds no state of its own beyond the
session and its login codes (auth), and never talks to Docker or GitHub.
Structs§
- Sessions
- Every credential of the dashboard: the session secret, kept in a file only the daemon’s user can read, which every signed-in browser holds in its cookie; the login links of a running dashboard; and the pairing codes.
Enums§
- Pair
Error - Why no pairing link was made.
Constants§
- DEFAULT_
ADDR - The dashboard’s default address.
- PAIRING_
LIFETIME - How long a pairing code works: enough to pick up a phone and scan it.
- PAIRING_
MAX - The most pairing codes alive at once; making another drops the oldest.
Functions§
- listen
- Binds the dashboard’s port from
runnerd serve --web: a loopback address, orofffor no dashboard. Only loopback: the session cookie travels in the clear. - login_
file - Where the daemon serving its API on
socketkeeps the dashboard’s login links, one per line: its loopback address first, then each of[web] origins.runnerd.sock→runnerd.web.runnerctl webreads it. - serve
- Serves the dashboard on
listenerfor the daemon whose API is onsocket, untilstopcompletes. Pages fromproxies([web] origins), reverse proxies in front of it, may write too. A browser signed in tosessionsis let in. Writes a one-time login link per address tologin_file(socket)and removes it when done. - session_
file - Where the daemon keeps the session secret: beside its job history,
database. - spawn
- Runs
serveas a task, logging why it stopped if it failed.