mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 12:47:04 +00:00
kevinveenbirkenbachandClaude Opus 5
d3b8ec4fc0
The per-matrix selection never picked anything but ext4. candidates() intersected what every distribution in the entry supports, and with the list the orchestrator passes - arch debian ubuntu fedora centos - that leaves ext4 alone: centos stream has no btrfs, zfs is debian/ubuntu only. btrfs was reachable only by stating it in the manual input. The intersection is right for swarm and wrong for the other two. distros.sh runs 00_one.sh per distribution and each round builds its own lab, so a swarm pick must hold in every round's nodes. compose and host carve the data root on the runner itself, whose OS is fixed; there DISTROS names the application images and has nothing to do with the filesystem underneath docker. A fourth argument says which, rather than parsing it out of the label, and guards with `:?` so a forgotten call site fails loudly. The runner pool omits zfs: the runner-image build installs neither the zfs userland nor linux-modules-extra, where the Ubuntu azure kernel keeps zfs.ko, so a drawn zfs would decline on every run. A stated one still overrides the pool and is marked required, so `filesystem: zfs` fails loudly instead of quietly falling back. The test executes the resolver rather than reading it, and pins the relation that breaks silently: the keys it writes to GITHUB_ENV are the keys the three workflows read. A typo on either side hands docker_dataroot.sh an empty string, which reports "no filesystem stated" and exits 0 - the feature switched off under a green run. Pool contents are policy and are not asserted; the per-distro expectation is derived from the resolver's own answers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Test Utilities 🧪
This directory holds the operational side of testing in Infinito.Nexus.
These assets are meant to support confidence, not ceremony. They help the project validate real-world behavior across local development, CI environments, and deployment-oriented smoke tests. The emphasis is on practical feedback: when something breaks, the surrounding test tooling should make the failure easier to understand, easier to reproduce, and easier to clean up. 🚀
Good changes in this area usually make the test experience more:
- repeatable
- diagnosable
- environment-aware
- safe to rerun
The ideal outcome is boring reliability: contributors should be able to trust that a test run says something meaningful about the system, not just about the machine that happened to execute it. ✅