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§
- Build
KeyReport - 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_versionis injected rather than probed so the computation is testable without a toolchain;rustc_versionis the real proberunuses. - 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:
$RUSTCwhen set (the pinned-toolchain convention every build script here follows),rustcotherwise. The version string is the input, not a parsed triple —rustc --versionis what a human compares.