Skip to main content

Module paths

runner_manager_platform

Module paths 

Source
Expand description

The four application-data directories the daemon owns, resolved to platform-standard locations.

05-infrastructure.md names them and says what each holds:

config/      non-secret TOML and SQLite database
state/       agent lock, attempt journal, retained runner package/cache
runtime/     per-attempt disposable directories
logs/        rotating redacted agent diagnostics

and then states the rule this module exists to enforce: “Platform-standard application-data directories are used; no repository or runner material is stored in the current working directory by default.”

§The invariant, and how it is tested

“Not the current working directory” is easy to satisfy by accident and easy to lose by accident — one PathBuf::from("state") anywhere in the resolution chain and the daemon starts writing runner workspaces wherever it happened to be launched from. The property that actually holds it is stronger and is what the tests assert: the resolved paths do not change when the process changes directory. A resolver that consults current_dir() fails that immediately, whereas an assertion phrased as “the path is not inside the current directory” passes for a developer whose shell happens to be somewhere else and fails for one whose shell is at $HOME.

§Placement, per platform

configstateruntime, logs
Windows%LOCALAPPDATA%\IvanMurzak\runner-manager\config…\data\state…\data\{runtime,logs}
macOS~/Library/Application Support/io.github.IvanMurzak.runner-manager…/state…/{runtime,logs}
Linux$XDG_CONFIG_HOME/runner-manager$XDG_STATE_HOME/runner-manager$XDG_DATA_HOME/runner-manager/{runtime,logs}

Three choices in that table are deliberate:

  • Local, not roaming, on Windows. config_local_dir rather than config_dir. A SQLite database and a runner package cache have no business being copied around a domain profile, and D13 stores this host’s token machine-scoped precisely because the agent is a machine-local thing.
  • $XDG_STATE_HOME on Linux. That is the directory the XDG base directory specification defines for exactly this content — state that survives a restart but is neither configuration nor portable data. It has no equivalent on Windows or macOS, so those fall back to a state subdirectory of the local data directory.
  • runtime/ is not $XDG_RUNTIME_DIR. That directory is a size-limited tmpfs that the system clears when the user’s session ends, and D13’s service starts at machine boot, outside any session — so it may not exist at all. runtime/ here holds per-attempt runner workspaces, which are large and must outlive a logout, so it lives under the local data directory instead.

Structs§

AppPaths
The four directories the daemon owns.

Enums§

PathsError
Something went wrong resolving or creating an application-data directory.