Runners for unusual platforms: a portable core and an honest host tier issue #90
open andymccall opened this · 0 comments
andymccall
Andy, 2026-10-26: is it worth a proper runner for platforms such as Haiku, FreeBSD or illumos? Cross-building proves code compiles; only a native runner proves the bytes pass their tests where they run, and a signed receipt for that is something no big forge offers for these platforms (GitHub's runner is .NET-bound, GitLab's is Go).
The cost is isolation: the MicroVM and syscall tiers are Linux, and flow-init is a Linux guest agent.
Sketch:
A portable runner core: claiming, fetching, the chunk cache, running a step, logs, reports and receipt signing, with nothing Linux-specific, so flow builds for any Rust target with std (Haiku, FreeBSD, NetBSD, illumos, macOS).
A host tier: the job runs as a plain process under the runner's user on a dedicated machine, in a fresh work directory removed afterwards. It is the weakest tier and says so: the tier is in the receipt, the provenance and the check's description, and a repository's policy can refuse it for releases (§11.1 tiers: MicroVM > syscall > WASM > host).
An environment fingerprint: with no rootfs image to pin, the runner reports and the receipt records the OS release, kernel, and the versions of named tools (environment { tool "rustc" "cargo" "gcc" }), so a result says what it ran on and a change of toolchain is visible.
Placement: a sandbox asks for runtime "host" and an os; runners offer it only with flow runner register --tier host, never by default.
See the matrix issue for how these runners are reached, and the VM-guest issue for the stronger option.
Andy, 2026-10-26: is it worth a proper runner for platforms such as Haiku, FreeBSD or illumos? Cross-building proves code compiles; only a native runner proves the bytes pass their tests where they run, and a signed receipt for that is something no big forge offers for these platforms (GitHub's runner is .NET-bound, GitLab's is Go).
The cost is isolation: the MicroVM and syscall tiers are Linux, and flow-init is a Linux guest agent.
Sketch:
flowbuilds for any Rust target with std (Haiku, FreeBSD, NetBSD, illumos, macOS).hosttier: the job runs as a plain process under the runner's user on a dedicated machine, in a fresh work directory removed afterwards. It is the weakest tier and says so: the tier is in the receipt, the provenance and the check's description, and a repository's policy can refuse it for releases (§11.1 tiers: MicroVM > syscall > WASM > host).environment { tool "rustc" "cargo" "gcc" }), so a result says what it ran on and a change of toolchain is visible.runtime "host"and anos; runners offer it only withflow runner register --tier host, never by default.See the matrix issue for how these runners are reached, and the VM-guest issue for the stronger option.