nordisk/dwarves

dwarves — SSH git-source + nornir warehouse submit

Two additive capabilities, both mirroring nornir and reusing shared crates (L5), with no nornir crate dependency (nornir→dwarves already exists; a dwarves→nornir edge would be a cycle — the *-embed pattern is used instead).

1. SSH git-source (IN)

The forge builds repos it clones over SSH — never https (LAW L6), never the git binary (L9).

• Deploy key. dwarves-server --install --system mints a pure-Rust ed25519 key at /home/dwarves/.ssh/id_ed25519 (mode 0600, chowned to the dwarves user) and prints the public half to paste as a repo deploy key — EXACTLY as nornir's install writes /home/nornir/.ssh/id_ed25519. The keygen (service::generate_deploy_keypair) is a faithful twin of nornir's generate_keypair (ssh-key + rand_core, OpenSSH format); it is wired next to ensure_dwarves_user. The shared keygen has not been lifted into a common edda/skidbladnir leaf yet — that hoist is the logged follow-up.
• Clone/register. dwarves repo add <ssh-url> (and crate::repo::add_repo) clones/fetches git@host:owner/repo.git or ssh://git@host/owner/repo into <repos_root>/<host>/<owner>/<repo>, authenticating with the deploy key. The git I/O is the SHARED edda/crates/nornir-git leaf — ssh::parse_ssh_url (parse/validate + derive the checkout path) and gitio::clone_or_fetch (gix + a russh SSH transport). An https:///git:// url is rejected before any I/O (gitio::is_ssh_url). The chosen design is the CLI verb + library seam; the native server-side RegisterPipeline git source (a proto source field on the dwarf.v1 RPC, so the SERVER clones on register) is now delivered — see server-git-source-and-live-report-design.md.

2. nornir warehouse submit (OUT)

On build completion the forge ships the build's record into nornir's unified warehouse so it shows up in the viz — the write counterpart to the read paths.

• RealRunner builds via nornir_build_thing::build_variant_with_info with an in-mem sink, capturing the provenance/dep/artifact/step/log/metric build-info rows (the §f3 schema, derived from BuildProvenance).
• Those rows are shipped by NornirWarehouseSink — an impl of nornir_build_thing::BuildInfoSink living in the nornir-warehouse-embed leaf. It maps each build-info row 1:1 onto a test_results row (aspect = build-<kind>) and submits them over nornir-server's Telemetry.SubmitTestResults gRPC (the contract in nornir/.nornir/data-submit-rpcs.md). No nornir crate dep — only the trimmed telemetry.proto (package nornir.v1) is compiled, the nornir-funnel-embed pattern. Auth/workspace headers reuse the same bearer + nornir-workspace metadata shape.
• Best-effort (L2). No NORNIR_SERVER ⇒ the sink is a no-op (local behaviour unchanged). A submit failure (server offline) is logged and swallowed — it NEVER fails the build. The submit runs on its own OS thread so it is safe inside the server's tokio runtime (no nested-runtime panic).

Build-provenance note (deferred)

nornir's Telemetry surface has SubmitBakeoff/SubmitTestResults/ SubmitReleaseEvents but no SubmitBuildProvenance/build-info RPC yet. So the build-info rows land in test_results (tagged aspect=build-<kind>) — the honest "did this build pass, and here are its facts" shape the 🧪 Test pane already renders. A native build_provenance/build_info submit RPC is the logged nornir-side follow-up.

3. Testability (L4 — observed from outside, RED-when-broken)

• nornir-warehouse-embed: the row mapping is asserted exactly; a mock Telemetry server receives the submitted rows (the whole serialize→submit→append contract); no-endpoint and offline both prove a clean no-op / best-effort success.
• crate::repo: an injected clone seam asserts a git@… url + the deploy key are routed through nornir-git, and that https:///git:// are rejected before the clone fn is ever called.
• crate::service: the deploy-key keygen mints a 0600 OpenSSH ed25519 key commented dwarves@…, idempotently.