mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-13 22:26:49 +00:00
kevinveenbirkenbachandClaude Opus 5.5
ca6faac318
Under act the deploy job pinned an engine but skipped the cache restores, so every local swarm-* run stopped on a missing Grype database. The swarm matrix also ran inside the act job container, where the shared host directory did not exist, and the workspace job would have kept a copy of about 5 GB in every worktree. - scripts/tests/deploy/act/workflow.sh requires INFINITO_VULNERABILITY_DB_HOST_PATH, creates it on the host and binds it into the job container at the same path, because that container drives the host daemon, which resolves every stack and swarm node bind on the host. - call-test-deploy.yml pins engine and database path in one step that runs only outside act; under act the deploy draws an engine and refreshes the shared directory. call-test-workspace.yml takes the shared path under act. - The refresh lock moves into the shared directory, so host deploys and act runs serialize on one file, and a root refresh hands its files to the directory owner. hand_over skips paths a mocked download never created, which failed four TestRefresh cases when the gate ran as root. - A missing INFINITO_VULNERABILITY_DB_HOST_PATH stops compose up with a "run 'make dotenv'" hint instead of a KeyError. - Rationale paragraphs in the database and compose docstrings are dropped. Part of #1324 Co-Authored-By: Claude Opus 5.5 <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. ✅