mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-13 22:26:49 +00:00
The swarm e2e now iterates one provision+deploy+e2e round per app variant, mirroring the compose matrix deploy, so the keycloak TOTP env-gate is no longer needed: the variant's services.keycloak.realm.totp_enabled=false is baked into host_vars per round and resolves at deploy time in swarm too. New cli/administration/deploy/swarm/matrix.py drives the rounds by reusing the compose planner (plan_dev_inventory_matrix, _resolve_variant_payloads, _bake_overrides): per round it provisions with the baked --vars overlay plus --app-variants, extends the swarm topology, deploys (e2e in-deploy), waits for convergence, and purges prior-round stacks between rounds via the new purge_stacks.sh. The workflow collapses its per-step provision/deploy/verify into one orchestrator step; chaos (seed/drain/assert) still runs once. - cli/administration/deploy/swarm/matrix.py: NEW round orchestrator - scripts/tests/deploy/swarm/purge_stacks.sh: NEW per-round swarm purge - scripts/tests/deploy/swarm/05_provision_inventory.sh: per-round inv dir plus conditional --vars / --app-variants (standalone path unchanged) - .github/workflows/test-deploy-swarm.yml: single orchestrator step, timeout 360 - default.env, utils/env/handlers/passthrough.py: register INFINITO_VARS_PAYLOAD plus INFINITO_APP_VARIANTS passthrough keys - roles/web-app-keycloak/vars/main.yml: drop the ENVIRONMENT env-gate Co-Authored-By: Claude Opus 4.8 (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. ✅