mirror of
https://github.com/open-jarvis/OpenJarvis.git
synced 2026-07-29 18:40:38 +00:00
krypticmouseandClaude Opus 4.7
c06633e26f
The `test` job runs only on ubuntu-latest, so the Windows-specific branches added for #373 (RAM detection via GlobalMemoryStatusEx) and #293 (cp9xx → UTF-8 stdout reconfigure) were never *executed* in CI — only unit-tested with mocks on Linux. `tests/hardware/test_hardware_profiles.py::test_total_ram_gb_windows` has existed all along but is `skipif(sys.platform != "win32")`, so it silently skipped on every run. This adds a `test-windows` job that runs on a real Windows runner (free for public repos) and: 1. Verifies `_total_ram_gb()` returns > 0 on actual Windows — executes the real `ctypes.windll.kernel32.GlobalMemoryStatusEx` path (#373). Runs as a pure-Python step BEFORE any Rust build, so a flaky toolchain install can't mask the result. 2. Runs `tests/hardware/test_hardware_profiles.py` (the now-unskipped Windows RAM test) and `tests/cli/test_cli.py` (the `test_windows_reconfigures_stdout_to_utf8` test from #293). 3. Builds + imports the `openjarvis_rust` PyO3 extension on Windows — the only CI job that does so. The extension is mandatory at runtime (`_rust_bridge.py` hard-errors without it), yet nothing else verified it compiles/imports on Windows. desktop.yml builds the Tauri app's Rust, not this extension. 4. Smoke-tests `jarvis --version`. Scoped to the platform-relevant test files (not the full 6700-test suite) so the job stays fast; the slow part is the Rust build, which doubles as Windows-extension-build coverage. All `run:` steps are static commands with no `github.event.*` interpolation — no workflow-injection surface. Note: #331 (desktop "did not become healthy" — uv sync error surfacing) is GUI-triggered Tauri boot logic and isn't covered here; its only automatable surface is string formatting, and testing it needs the heavy webview build. Left as a possible follow-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>