Native FreeBSD runners: flow built and run on FreeBSD, host tier issue #99 open andymccall opened this 7 days ago · 1 comment

State, 2026-10-29 01:00 GMT: a FreeBSD 15.1 VM runs on mars (user unit freebsd-vm, 2 cores, 1.5 GB + 2 GB swap file, SSH on mars 127.0.0.1:2223; /mnt/development/freebsd/fssh from the workstation). pkg's Rust is 1.98.1, new enough for wasmtime 49, so FreeBSD keeps the WASM tier. flow builds there with -j 1 (two rustc at once ran out of memory), after the same noatime fix Haiku needed (only Linux's statvfs has the flag).

Proposal, for Andy to decide before it is built: the host tier. On Haiku, flow tiers says no tier runs; on FreeBSD only WASM does. A native runner there needs issue #90's host tier:

• runtime "host" in a pipeline's sandbox (flow-core: a fourth Runtime; the hub and the Android app's rust-core match on it, so they take the new pin with it).
• The job runs as a plain process under the runner's user: a fresh work directory with the job's files at ./, the job's env only, the time limit and cancel as the other tiers, the directory removed after. No isolation at all: only for a dedicated machine, which is why it is opt-in twice, [runner] host = true in flow.toml and a site setting on the hub.
• The receipt says runtime: host and carries an environment fingerprint instead of a rootfs hash: the OS and its release, the kernel, and the versions of the tools the job names (env.FLOW_HOST_TOOLS = "cc rustc python3", each asked for --version).
• Trust: a host-tier pass never satisfies a check that requires an isolated tier (issue #79), and a repository's policy can refuse host-tier receipts for releases.

Not built tonight: it changes the pipeline format and runs untrusted code unisolated, so it wants your yes first.