mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-09 20:26:33 +00:00
kevinveenbirkenbachandClaude Opus 5
98396dcfbb
The script stops the daemon at :157-158 and starts it again only on the success path at :220. decline() exits 0 and set -e exits non-zero, and both walk past that start, so any other outcome leaves the host without docker. One of the three callers is test-deploy-host.yml:171, where the script runs on the GitHub runner itself rather than in a lab node container. An EXIT trap rather than a restart inside decline(), because decline is not the only affected exit: arm_autoclear's exit 1 and every set -e abort at mkdir, truncate, zfs create, mkfs, mount, btrfs subvolume create and the daemon.json writer sit in the same window. The trap is armed only after the stop, and DOCKER_STOPPED=false after a successful start makes it a no-op on the green path. A failed restart is reported rather than swallowed, so it cannot hide the failure that led there. This hazard predates 02dc003bb: the loop-device decline added in the commit before it has the same property. 02dc003bb widened it by putting a second decline behind the stop. Verified with a stubbed-PATH harness driving the real script: after a failed zpool create the call log contains `systemctl start docker`, and it comes after `losetup -d`, so the teardown still precedes the restart. REQUIRED=true still exits 1, the success path is unchanged. 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. ✅