mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-09 04:06:42 +00:00
kevinveenbirkenbachandClaude Opus 5
a37039f0cb
The instructions test brings up a machine per role, so it can only ever replay one guide. Which one it picked was a side effect of ordering: the lookup returned the first invokable peer the round listed, and on a CI row that is the role under test only because the row's apps happen to read <role>,web-app-docs. It now reads APP_ID, which the deploy workflow already sets to the row's app and which the swarm routine already documents as the app under test. A round that carries no APP_ID, or one whose app publishes no Production block, draws an invokable peer at random instead, so a local round covers a different guide each time rather than always the first one the inventory lists. Ansible runs inside the infinito container rather than on the runner, and that exec passes an explicit allowlist, so the name arrives only where it is forwarded. Two seams carry it: _FORWARDED_ENV_KEYS, which covers CI and the local initialize and reinstall verbs, and the update verb's own docker exec, which assembles its arguments without that CLI. The pin is tolerant rather than strict. APP_ID is set on every deploy row and not only on documented ones, so refusing an app that publishes no guide would let a generic variable abort a deploy. Measured: the draw is observed over 200 rounds rather than assumed, and the forwarding is negative-controlled, removing the key and watching the new test fail on that key alone. 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. ✅