novox/mesh-catalog
18
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Say in the build modules' READMEs that they build with the installed toolchain, the digest holds no Go version, and the reference is agreement between build nodes (issue 1572, ADR 0477)

Browse Source
This commit is contained in:
mesh-tools
2026-10-21 08:05:55 +00:00
parent edec7063b3
commit e8046fca87
1 changed files with 9 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modules/mesh-build-node/README.md
+9 -6
View File
@@ -9,9 +9,11 @@ provisioner's client (issue 1537).
## The recipe
`recipe.go` names the one Node version it builds with (`RecipeNode`, `v26.10.0`, as `node --version` prints it) and the
recipe's own version (`RecipeSteps`). The recipe version is a hash of those two and of the bytes of the lock file
`toolchain/package-lock.json`, so one changed byte of the lock, another Node or another recipe moves it.
The module builds with the `nodejs` and `npm` its node has installed and names no Node version (ADR 0477 §1, issue
1572); the versions of the build nodes are agreed by the indexer (ADR 0465) and kept equal by the weekly upgrade of
every node's packages (ADR 0477 §5). `recipe.go` holds the recipe's own version (`RecipeSteps`). The recipe version is a
hash of that and of the bytes of the lock file `toolchain/package-lock.json`, never of a Node version (ADR 0477 §3), so
one changed byte of the lock or another recipe moves it, and typescript and esbuild change only when the lock does.
## The toolchain directory
@@ -34,9 +36,10 @@ separately: sdk and nats are in this directory's `node_modules`, and the build s
At start, every ten minutes, before every step and at every health look, the module reads the lock again and the
installed Node (`node --version`) and writes it with the recipe version to `<node>.typescript` of its `toolchains`
state. A machine whose Node is not the recipe's refuses every step, the step ending `refused` on its key in `steps` with
both versions named, and `build_node_health` (the module's `runtime-health`) answers unhealthy with the same text, so
the controller raises the machine's condition. A step runs only after the toolchain directory is installed.
state. Whatever the version, the module is healthy and `build_node_health` (the module's `runtime-health`) names it. Only a
`node` that cannot be run, or a lock that cannot be read, refuses every step, the step ending `refused` on its key in
`steps` with the cause named; the health is then unhealthy with the same text, so the controller raises the machine's
condition. A step runs only after the toolchain directory is installed.
## Tools