mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 12:47:04 +00:00
kevinveenbirkenbachandClaude Opus 5
ad92226307
web-app-openwebui 0,1,2 was killed by the 350-minute action timeout with no failed task anywhere in its 1.33M log lines. The sweep admitted fedora at remaining=10372s after debian took 10028s, then never looked again: the budget was only checked between distros. Its internal deadline passed 594 seconds before GitHub killed the job - the run knew it was over time for ten minutes and had no way to act. Worst-case runtime was deadline plus the full duration of the last admitted distro, unbounded. The trigger was a single stalled task (803s for a no-op that takes 1.3s warm, and a fully cold transaction 8 minutes later cost 24s), but that only decided which job hit the wall. The wall itself is structural. remaining is already computed at the top of the loop, so wrapping the call in timeout adds no new state. rc 124 becomes 'skipped' rather than 'failed', because a job that stops at its budget is the documented intent, not a defect - test_distro_budget_fits_timeout.py already asserts this invariant, which until now was simply untrue. Two conditions narrow it, and both matter: dur >= remaining - 5 keeps an inner timeout that fires early as a failure. Verified: timeout returns 124 only for its own kill and passes inner exit codes through unchanged (0 for success, 3 for an inner exit 3). passed > 0 is the one that protects the test result. Without it, a job whose very first distro overruns would report 'skipped' and exit 0 - green while having verified nothing. That would have been a silent false pass across all 243 jobs of a run. The guard was executed over the full truth table, including passed=0. -k 60 is deliberate: one.sh execs into dedicated.sh and its ansible and docker children can outlive SIGTERM. 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. ✅