mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 12:47:04 +00:00
kevinveenbirkenbachandClaude Opus 5
05f425ea51
The quiesce guard spelled the dev container as the literal infinito_nexus_debian, so it only ever matched a checkout whose .env was generated for debian without a project prefix. It missed the self-hosted runner form infinito_<project>_nexus_<distro>, any custom.env pin, and any .env generated for another distro — and it missed them silently, because a non-matching grep just skips the block and leaves the competing onion publisher running. INFINITO_CONTAINER is the SPOT for that name: compose.yml uses it as container_name, and scripts/meta/env/load.sh (already sourced at line 19) exports it. Proven against the container running on the author's host: the literal does not match it, the variable does. The outer `docker ps | grep -qx` pre-check is gone with it — `docker exec` on an absent container already exits non-zero with stderr suppressed, and the `if` absorbs that even under `set -euo pipefail`. The variable joins the line-21 assertion so a broken env fails by name instead of dying inside a pipeline subshell, which would reproduce exactly the silent-skip class this commit removes. compose.yml already requires the same variable with `:?`, so this is not a new demand on the environment. tests/lint/repository/test_no_hardcoded_container_name.py pins it: run against the pre-fix file it flags all three lines, and it stays green on the distro-agnostic spellings in stack_refresh.sh and worktree/up.sh. 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. ✅