nordisk/dwarves

Dwarves

CI/CD software forge inspired by the dwarven craftsmanship that created Odin's spear Gungnir and the gods' treasures, as recorded in the Icelandic Prose Edda (c. 1220 CE).

It binds tightly to Nornir — handling code's time-space dimensional warehouse — and to Holger, the artifact registry guarding your artifacts at rest.

Measured — the forge's planner hot paths

Dwarves release — usage

Dwarves release is a multi-language, industrialised implementation of cunning, the cargo/crate spec, and academia — built to solve the Codeberg/Nordisk release: 154 crates across 17 repos, cross-repo cycles and all.

dwarves workspace-release .             # DEFAULT dry-run — PLAN ONLY: plan the constellation, no build, no branch
dwarves workspace-release . --verify    # + the pre-publish cargo-test suite
dwarves workspace-release . --rehearse  # + Gate-B: rehearse the cascade into a throwaway local registry
dwarves workspace-release . --execute   # for real — verify + rehearse, then crates.io (only after both gates pass)

The run is tiered and cheap-first, build-last: the default dry-run plans only (deps-first order, ship-versions, the static Gate-A precheck, advisory graph analysis) and STOPS — no build, no cargo test, no branch — in milliseconds. --verify adds the cargo-test suite; --rehearse adds the Gate-B /sparring rehearsal; --execute implies both (a real publish always verifies + rehearses), then uploads. Nothing reaches crates.io until two gates go green — Gate A (static) and Gate B (a rehearsal into a throwaway local registry). A build never runs on an already-failed run, and a --verify/--rehearse dry-run builds into the same target --execute reuses, warming its cache.

In the Dwarves UI, the picture below shows a dry-run error — caught by the static Gate A in milliseconds, before any build. With --rehearse/--execute, Dwarves also builds the whole cascade into a staged Holger (a local repo):

Fix the culprit and run again — green means the cascade publishes deps-first:

📖 Release pseudocode (Rust) — the dry-run step by step, the two gates, and the formal model, with diagrams.

📐 Release invariants — what a release guarantees, independent of how it is sequenced: the cross-repo dependency model, the invariants upheld today, the ones measured as absent, and why a gate can state the right condition and still be green by construction.

The release process is AI-free — 100% dwarven-forged: deterministic Rust, no model in the loop.

Dwarves tune — the Heimdall tuner

dwarves tune measures a Build Thing row's programs into seccomp profiles, has a person review them, and gates on drift. <artifact> is a row (rusternetes-node, in the checkout you stand in) or <repo>:<row> (tunnr:rusternetes-node, a checkout beside it or under --checkouts).

dwarves tune probe   rusternetes-node                    # probe + gen: profiles beside the row
dwarves tune probe   rusternetes-node --workload smoke   # + the runs of the [[driver]] "smoke"
dwarves tune gen     rusternetes-node                    # regenerate from the probe evidence (no probe)
dwarves tune approve rusternetes-node --note "reviewed"  # record the review in approved.toml
dwarves tune check   rusternetes-node                    # fail on a new call or an unapproved profile
dwarves tune check   tunnr:rusternetes-node --json       # the same, as the stable JSON document

The row lives in .nornir/profiles/<row>/measure.toml (its programs, runs, optional [[driver]] workload drivers, and the heimdall tool pinned by version and sha256). approve writes approved.toml beside it: per program and libc, the sha256 of each reviewed .json / .oci.json, the reviewer's name from git config user.name (never an e-mail address), the date and the note. After that, check fails on any profile that changed since its approval: not approved: <program> <file> changed since <date>.

A workload driver without command adds corpus runs, named <driver>/<run>. A driver with command drives a served app (the served-app runner comes from lane HEIM-APP; until it lands, such a driver is refused by name). gen and check reuse the drivers the last probe used.

Every verb prints text, or one JSON document with --json (schema dwarves.tune/1: ok, tool, programs, checked, drift, out_of_sync, vm_later, approval, problems, next, text; a refusal is {ok: false, error}). The exit code is 0 when ok, 1 on findings and 2 on a refusal. A missing tool, an unbuilt binary or an unknown row is one line that names the fix.

The licence boundary: Heimdall is AGPL-3.0-only and dwarves is MIT OR Apache-2.0. dwarves tune calls edda's nornir_build_thing::measure, which runs the heimdall binary as a separate process and reads its JSON. No heimdall crate is linked.

Every crate in the constellation is held to Brokkr's Software Criteria — baremetal, minimal-dependency, zero-copy / multi-core / SIMD.