nordisk/gunnar

crates/gunnar-recipe/tests/iso_edge_linked.rs

//! **Does the crate gunnar LINKS see the live iso's kernel edge?** — RED on
//! the 0.1.9 pin on purpose for one day, GREEN since the pin advanced.
//!
//! Wave 3, the iso-edge work, 2026-08-27, after the wave-2 audit named it: the
//! toml declares `[build.iso.kernel_donor] tunnr/tunnr-kernel`, and the FORGE
//! consumed it — dwarves links edda main, whose `IsoBuild` carries
//! `kernel_donor`, so `dwarves buildthing gunnar --variant gunnar-appliance-iso`
//! resolved the kernel through the edge on both doors. But THIS crate resolved
//! `nornir-build-thing` from the registry at 0.1.9, whose `IsoBuild` has no such
//! field: the loader gunnar's own binaries link dropped the table silently, and
//! the Rust mirror carried the value only as a free function
//! (`recipe::iso_kernel_donor`). "The edge is landed in gunnar" was therefore
//! false until the crate gunnar links had the field — and a raw-file guard
//! (`tests/toml_parity.rs`) could not say so, because it never asks the linked
//! loader.
//!
//! This test asks the linked loader. It reads the loaded struct's `Debug`
//! rendering rather than a field, so it compiles under either pin, and it was
//! written to go green the day the field exists — by the pin advancing, never
//! by the assertion being weakened. No `#[ignore]`, no feature gate, no
//! `should_panic`; that was the point.
//!
//! # Both sides seen, 2026-08-27
//!
//! * RED on `nornir-build-thing 0.1.9` (measured by downgrading the
//!   lock in place): the panic printed the whole loaded `IsoBuild` and there is
//!   no `kernel_donor` key anywhere in it — `IsoBuild { name:
//!   "gunnar-appliance-iso", kernel: "", rootfs: "", staging: …, format: Uefi,
//!   from_variant: Some("gunnar-server"), … }`. The field is not empty; it does
//!   not exist.
//! * GREEN on `0.1.10`, published the same day (wave-3
//!   decision R1). The repair was a plain version bump — NOT the
//!   `[patch.crates-io]` road the earlier note weighed, which stays forbidden
//!   here: a patch table is a structural publishing blocker in this
//!   constellation.
//!
//! Keep this test. It is the only one that asks the loader gunnar's BINARIES
//! link, as opposed to the one dwarves links, and those are different crates
//! whenever the pin lags edda.

use std::path::{Path, PathBuf};

use nornir_build_thing::variant::BuildVariantSet;

fn repo_root() -> PathBuf {
    Path::new(env!("CARGO_MANIFEST_DIR"))
        .parent()
        .and_then(Path::parent)
        .expect("crates/gunnar-build-thing has two ancestors")
        .to_path_buf()
}

#[test]
fn the_linked_loader_carries_the_live_isos_kernel_donor() {
    let path = BuildVariantSet::conventional_path(&repo_root());
    let set = BuildVariantSet::load_file(&path)
        .unwrap_or_else(|e| panic!("load {}: {e:#}", path.display()));
    let iso = set
        .isos
        .iter()
        .find(|i| i.name == "gunnar-appliance-iso")
        .expect("the live iso is declared");
    let mirror = gunnar_recipe::iso_kernel_donor();
    let want = format!(
        "kernel_donor: Some(KernelDonor {{ repo: {:?}, kernel: {:?} }})",
        mirror.repo, mirror.kernel
    );
    let seen = format!("{iso:?}");
    assert!(
        seen.contains(&want),
        "the nornir-build-thing this crate LINKS (registry pin, see Cargo.toml) loaded the live \
         iso WITHOUT its kernel edge — the toml declares [build.iso.kernel_donor] {}/{} and the \
         forge (edda main) consumes it, but gunnar's own loader has no IsoBuild.kernel_donor and \
         dropped the table. The repair is a pin that carries the field (0.1.10 published, or the \
         pin that carries the field, as 0.1.10 does) — never by weakening this \
         assertion. Loaded: {seen}",
        mirror.repo,
        mirror.kernel
    );
}