# skade CI/build pipeline — driven by the dwarves forge (brokkr descriptor +
# sindri scheduler). `dwarves validate` / `dwarves plan` / `dwarves run [--real]`.
#
# WHY THIS FILE EXISTS (MEASURED 2026-08-25): skade had none. Across the whole
# constellation — 38 repos under ~/git — `nornir/brokkr.toml` was the ONLY pipeline
# declaration until Skidbladnir got one this morning. skade is the GRAPH ROOT of
# the suite build matrix; nothing is downstream of it, so the repo everything else
# is built on top of was one the forge could not plan.
#
# WHICH STEPS BUILD AND WHICH RUN — and why this repo, uniquely among the six,
# declares no `run = { tests = … }` step at all.
#
# `run = { variant = … }` BUILDS. `nornir_build_thing::build_variant`, a real
# cargo build under `--real`.
# `run = { tests = … }` RUNS. `RunKind::Tests` (dwarves `abe10d4`) reuses the
# same variant's `cargo_args()` with `build` swapped for
# `test`, through `buildgate::run_cargo`.
#
# A `tests` step resolves its variant to a PACKAGE and runs cargo at the repo root,
# exactly as a build step does. Neither of skade's two variants can be named from
# the repo root at all (see the measured block below), so a test step here would
# fail for the same reason its build does — and would misreport a layout defect as
# a red suite. Both are declared as builds only, and the reason is written down
# rather than left as a mystery. `RunKind::Container`/`Vm` remain unwired.
#
# The two steps name the two rows in `.nornir/build-variants.toml` and nothing
# else. They carry no `needs` edge: the library and the serve binary live in
# separate cargo workspaces and neither's build consumes the other's output.
#
# ═════════════════════════════════════════════════════════════════════════════
# ⚠ READ THIS BEFORE `dwarves run --real`: BOTH VARIANTS ARE UNBUILDABLE FROM THE
# REPO ROOT TODAY, AND IT IS A REPO-LAYOUT DEFECT, NOT A PIPELINE ONE.
# ═════════════════════════════════════════════════════════════════════════════
#
# `build_variant` runs cargo with `cmd.current_dir(repo_root)`
# (`edda/crates/nornir-build-thing/src/provenance.rs:474`) — one cargo invocation,
# at `/…/skade`. The root workspace there is:
#
# skade-katalog@0.1.20 (the root package) · vendor/iceberg-arrow59
# vendor/iceberg-datafusion-arrow59 · vendor/iceberg-catalog-rest-arrow59
# bench/aegir → skade-aegir@0.1.1
#
# (measured with `cargo metadata --no-deps` on this checkout). Neither variant's
# package is in it. `skade/` and `serve/` each declare their OWN `[workspace]`
# (skade/Cargo.toml:241, serve/Cargo.toml:82) — deliberately detached, so the
# published skade-katalog manifest and lockfile stay untouched and the arrow-59
# tree does not have to reconcile with the root's. Measured, verbatim:
#
# cargo build -p skade --lib --release --features s3
# → error: cannot specify features for packages outside of workspace
# cargo build -p skade-katalog-serve --bin skade-katalog --release
# → error: package ID specification `skade-katalog-serve` did not match any packages
#
# So skade's ENTIRE declared build space is unreachable by the forge's one build
# entry point, and the thing the root CAN build — `skade-katalog`, the published
# crate, a real shipped artifact — has no variant at all. The steps are declared
# anyway, because they are what this repo declares it ships and a forge red that
# names the real defect beats silence that hides it. THE FIX IS A DECISION, not an
# edit: either the detached workspaces join the root (giving up the reason they
# were detached), or `build_variant` learns a per-variant working directory, or
# skade declares a `skade-katalog` variant for the artifact it actually publishes.
# None of those is this file's to make.
#
# ⚠ DARK TESTS, counted on this checkout 2026-08-25 — 19 `#[test]`/`#[tokio::test]`
# fns behind a feature no variant enables:
#
# uring 11 bench/aegir/src/uring.rs, gated at src/lib.rs:34 — a LIBRARY
# unit-test module, the shape `nornir_testmatrix::audit_repo`
# cannot see (it walks test TARGETS). `uring` is not even in
# `[build] offers`, so it is invisible to the build space too.
# lineage 6 skade/tests/lineage.rs
# testmatrix 1 tests/testmatrix_wiring.rs
# lineage-http 1 skade/tests/lineage_http.rs
# stream 0 skade/tests/stream.rs — the file is empty of tests, which is
# its own finding: a gated file that proves nothing.
[pipeline]
name = "skade-ci"
[[pipeline.trigger]] # fire when the poll sweep sees HEAD move
kind = "poll"
events = ["push"]
[[pipeline.trigger]] # …and nightly at 04:20 (off nornir 03:00 / skidbladnir 03:20 / modgunn 03:40 / edda 04:00)
kind = "cron"
cron = "20 4 * * *"
# ── what skade declares it ships ─────────────────────────────────────────────
[[pipeline.stage]]
name = "build"
[[pipeline.stage.step]]
name = "engine"
# `skade` — the LIBRARY a consumer compiles in-process (kind=lib,
# linkage=not-applicable), with the `s3` object-store backend on.
run = { variant = "skade" }
[[pipeline.stage.step]]
name = "katalog-serve"
# `skade-remote` — the one lock-owning `skade-katalog serve` process that thin,
# lock-free consumers reach over gRPC / Iceberg-REST. kind=service, linkage=fat:
# it OWNS the warehouse state and needs nothing else running.
run = { variant = "skade-remote" }
[[pipeline.stage.step]]
name = "flight-sql"
# `skade-flight` — the SQL door: Apache Arrow Flight SQL over the warehouse
# (DataFusion 55 in, streamed Arrow out) for Power BI / ODBC / ADBC clients.
# Same detached-workspace caveat as the two steps above (manifest_dir =
# skade-flight); same kind=service, linkage=fat: it opens the warehouse itself.
run = { variant = "skade-flight" }