A real matrix: fan-out per platform, os placement, optional cells, a results grid issue #89
open andymccall opened this · 0 comments
andymccall
Andy, 2026-10-26. Oxygen started because CI runners for RISC-V were scarce; OxygenFlow already runs on x86_64, aarch64, riscv64, Windows and Android, but a pipeline cannot ask for "this job on each of these platforms".
Today: runs-on labels, arch on a sandbox, a rootfs per architecture (rootfs { x86_64 …; riscv64 … }, which runs the job once on whichever architecture takes it), and artifacts between jobs (input { artifact … from … }). There is no fan-out, the runner's reported OS is never matched, and a job no runner can take simply waits.
Sketch:
Fan-out.matrix { target "linux-x86_64" "linux-riscv64" "windows-x86_64" "haiku-x86_64" } on a job: one job per cell, named test (linux-riscv64), each its own check. Several axes multiply; exclude and include trim and add cells.
OS as a placement key.os "haiku" beside arch, matched against what a runner reports (§11.1), so platforms are not reached by label convention. The waiting reason names the OS.
Optional cells.optional on a cell or axis value: it runs when a runner can take it, and its failure or a missing runner (after a set wait) does not block landing. For scarce runners (one narvi, one phone) and tier-3 targets.
Results grid. The run page shows targets × jobs; required checks can name test (*) or particular cells.
Cross-build, native test. A matrix job's input { artifact "bin" from "build" } takes the same cell's artifact, so a pipeline builds every target on a fast Linux runner and tests each where it runs.
Receipts and provenance record the cell (target, os, arch, image or environment).
Andy, 2026-10-26. Oxygen started because CI runners for RISC-V were scarce; OxygenFlow already runs on x86_64, aarch64, riscv64, Windows and Android, but a pipeline cannot ask for "this job on each of these platforms".
Today:
runs-onlabels,archon a sandbox, a rootfs per architecture (rootfs { x86_64 …; riscv64 … }, which runs the job once on whichever architecture takes it), and artifacts between jobs (input { artifact … from … }). There is no fan-out, the runner's reported OS is never matched, and a job no runner can take simply waits.Sketch:
matrix { target "linux-x86_64" "linux-riscv64" "windows-x86_64" "haiku-x86_64" }on a job: one job per cell, namedtest (linux-riscv64), each its own check. Several axes multiply;excludeandincludetrim and add cells.os "haiku"besidearch, matched against what a runner reports (§11.1), so platforms are not reached by label convention. The waiting reason names the OS.optionalon a cell or axis value: it runs when a runner can take it, and its failure or a missing runner (after a set wait) does not block landing. For scarce runners (one narvi, one phone) and tier-3 targets.test (*)or particular cells.input { artifact "bin" from "build" }takes the same cell's artifact, so a pipeline builds every target on a fast Linux runner and tests each where it runs.Receipts and provenance record the cell (target, os, arch, image or environment).