Skip to main content

Module build_key

Module build_key 

Source
Expand description

fz build-key: the artifact’s content address, computed and shown outside any build (issue #59).

The artifact is a pure function of the module set and their exact versions, the harness API, the rustc that will compile it and the profile it compiles under — cratefield_manifest::build_key() is the identity, this command is its inspection surface. A cache (whose physical home is a control-plane decision) looks a compiled venture up by this key; fz build-key exists so CI, the control plane and an operator can compute and compare the address before any cargo invocation.

What is deliberately not an input: the venture name, host, config, seed data and the sidecar mount table. Those are per-customer deployment configuration — two customers sharing a module set share the artifact and still get separate Workers, databases and secrets, and one wasm serves customers whose sidecar mounts differ, which is what makes the cache real (issue #59, as amended).

Structs§

BuildKeyReport
A computed key together with the canonical form of the inputs that produced it, so a caller (or test) can assert on the inputs, not only the hash.

Functions§

compute_with
Computes the build key for a manifest. rustc_version is injected rather than probed so the computation is testable without a toolchain; rustc_version is the real probe run uses.
run
Runs fz build-key. Prints the key, then the inputs that produced it. Reads nothing but the manifest (and an optional catalog); runs no cargo, writes nothing.
rustc_version
The rustc version the artifact would compile under: $RUSTC when set (the pinned-toolchain convention every build script here follows), rustc otherwise. The version string is the input, not a parsed triple — rustc --version is what a human compares.