CI's lint job ran ruff check but never ruff format --check, letting format drift land silently (79 files had drifted from the pinned ruff 0.15.1). Add the ruff format --check step to ci.yml, reformat the 79 drifted files with the pinned ruff (mechanical only — verified AST-identical to before across all files, no logic changes), and add a Makefile whose test target mirrors the actual CI lane.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Run pytest with -n auto (pytest-xdist) and COVERAGE_CORE=sysmon, enable the uv cache, and switch test output to -q. Cuts the test job from ~40min to ~4min without changing what's tested or the 60% coverage gate.
The two eval-dataset suites that download real corpora from the
HuggingFace Hub at runtime were running in the default CI lane. When the
Hub was unreachable or rate-limited they failed and reddened `main` even
though no code changed — confirmed by #506 (docs-only) failing on merge
while its own PR run passed an hour earlier. They also dominated CI
wall-time (~33 min of downloads + retry backoff on the failing run).
Add a `hub` pytest marker, apply it to both suites via module-level
`pytestmark`, and exclude it from the default CI lane
(`-m "not live and not cloud and not hub"`). The tests stay runnable on
demand with `pytest -m hub`.
The ADP provider swallows per-config download errors and returns 0
records on a network failure, so a Hub outage surfaced there as
`assert 1 <= 0` (not an exception) — it could not be made non-flaky by
exception handling alone, only by gating.
Coverage holds: removing these from CI drops total from 60.92% to
~60.73% (paranoid worst case 60.18%), still above the 60% gate.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fixes#350 (API server fails to start on Windows because numpy has no cp314 wheels).
Caps `requires-python` to `>=3.10,<3.14` in pyproject.toml so uv resolves a Python that has working numpy wheels on Windows. Extends the `test-windows` CI matrix to run on both Python 3.12 and 3.13 to keep the cap honest.
Reported by @RizaldyMongi in #350. Thanks for the careful repro — the Windows-only fallout was tricky to reproduce on Linux/macOS and the issue gave us the exact symptom signature to triage from.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
Ahead of the 2026-06-02 forced-Node-24 deadline, upgrade the remaining
javascript actions flagged in the workflow annotations:
- actions/setup-python v5 → v6
- actions/setup-node v4 → v6 (skipping v5)
- actions/cache v4 → v5
- actions/deploy-pages v4 → v5
- actions/upload-pages-artifact v3 → v5.0.0
upload-pages-artifact has no rolling @v5 major tag — only the specific
v5.0.0 release — so it gets an explicit pin, same as astral-sh/setup-uv.
Not touched: swatinem/rust-cache@v2 (still on v2 majors, not flagged),
dtolnay/rust-toolchain@stable (composite), tauri-apps/tauri-action@v0
(composite), anthropics/claude-code-action@v1 (still latest major).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
astral-sh/setup-uv does not publish a rolling @v8 major tag — only the
specific v8.0.0 release. Previous commit's @v8 reference failed to
resolve and broke CI/Docs/PyPI-publish runs.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- openjarvis.__version__ now comes from importlib.metadata.version("openjarvis")
instead of a hardcoded string, so it stays in sync with pyproject.toml on every
release. Tests assert against openjarvis.__version__ rather than a literal.
- Bump actions/checkout@v4 → @v6 and astral-sh/setup-uv@v4 → @v8 across every
workflow ahead of the 2026-06-02 Node.js 20 deprecation on GitHub Actions runners.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The gemma_cpp live tests require local model weights and env vars
(GEMMA_CPP_MODEL_PATH, etc.) that are not available in CI, causing
4 failures since the gemma-cpp-engine PR was merged. Add marker
filters to the pytest invocation so live and cloud tests are skipped.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
