Crate runnerd_core 

Domain logic and API types shared by the runnerd daemon and its clients.

api and config build everywhere. The host feature (on by default) adds what only the daemon runs: Docker, the GitHub client, the caches, the scheduler, the job history store and what observes running jobs. Clients depend on this crate without it.

Modules

api

The daemon’s JSON API, version 1: the request and response types every client deserializes, and the principal a transport authenticates. Plain data only: no I/O, no Docker or GitHub types, no secrets.

cache

The warm caches runner containers share and keep between jobs: each profile’s read-only snapshot, each slot’s volume (its layers’ changes and its Docker Engine’s data), the shared pnpm store and Maven repository, and the Docker Hub mirror on the runners’ network. Owns their names, mounts and lifecycle; it never decides when a runner starts, and it never touches a volume a running container uses.

config

runnerd.toml: the repositories to serve, the runner profiles they use, the shared caches and the host budget they must fit in. Builds without the host feature, so clients can read a config; its only I/O is reading the file and asking systemctl for a slice’s MemoryMax. It never talks to Docker or GitHub.

docker

Runner containers through the Docker Engine API: the connection, container, volume and image requests, and the DockerApi trait the engine and the caches call. It decides nothing about scheduling, and a JIT config only ever reaches a container as a root-only file, never the create request or a log line.

github

The GitHub REST API as the scheduler needs it: queued jobs, just-in-time runner configs and repository runners. Owns the token, conditional requests and rate-limit backoff. It must never put the token in a log line, a Debug output or an error, and it decides nothing about scheduling.

isolation

How a runner container is kept from the host while it runs its own Docker Engine. A backend decides only how the container is created; its name, limits, labels and slice are the same for every backend (docker).

observe

What runnerd learns about running jobs without GitHub’s help: CPU, memory and network of each runner container from its cgroup v2 files and /proc (metrics), the job a runner took and its log from inside the container (capture), and which runner pulled what through the Docker Hub mirror (mirror). Reads files and parses output; it starts no container, writes nothing to the host, and decides nothing about scheduling.

scheduler

Which runners to start and stop, as a pure function of queued jobs, slots and the memory budget (plan), and the loop that applies those decisions with GitHub and Docker (engine). plan does no I/O and reads no clock.

store

The job history: a SQLite database of jobs, their runners, steps, samples and logs, the events clients resume from, cache sizes and the paused repositories. Owns the schema and its migrations, the one writer and the event broadcast. Writes are messages to a writer thread, so the engine never waits on the disk; reads run on Tokio’s blocking pool. It decides nothing about scheduling and stores no secret: no token, no JIT config, no runner _diag log.