5 Commits

Include renames

Author	SHA1	Message	Date
James Mackay	fd62d850b7	fix(drift): F1+F2 — the sweep refuses false greens, and CI provisions the real floor (t39) ... t38 found two holes in the drift gate itself. F2 — the job could never run where it mattered. Home Assistant 2026.10.1 declares ``Requires-Python >=3.14.2`` (PyPI metadata), so the old guard let a 3.13 runner through and the ``homeassistant>=2026.10`` install then failed with a resolver error. The job now provisions its own interpreter (``actions/setup-python@v5`` with ``python-version: "3.14"``) and the guard runs against the REAL floor, read from ``ha_api_drift.HOMEASSISTANT_PYTHON_FLOOR`` — one source of truth, pinned by a test against the installed distribution's own ``Requires-Python`` metadata. Verified: on 3.13.16 the guard refuses with "Home Assistant needs Python >= 3.14.2, but this job runs 3.13.16 / Fix: raise actions/setup-python…"; on 3.14.8 it reports "interpreter ok"; and ``uvx --python 3.14 --with 'homeassistant>=2026.10'`` resolves 2026.10.1. F1 — the standalone entry point was a false green. It printed counters and exited 0 even when it had walked nothing, which is exactly how the manual red-proof tool gets misused. The non-vacuity floors now live in ``ha_api_drift.FLOORS`` and are enforced in ONE place, ``Report.floor_violations()``, used by the pytest wrapper and by ``__main__`` (so the constants cannot drift apart; a test asserts the wrapper holds no floor-like constants of its own). On top of that the sweep can no longer lie in either direction: * an empty or mis-targeted directory reports ``FLOOR:`` lines and ``drift sweep FAILED`` and exits 1 (a non-existent path is a ``bad-path`` finding, not a traceback and not a silent zero-module sweep); * with no homeassistant installed it returns a single ``no-homeassistant`` finding with zero counters — never a wall of phantom "broken-import"s, never a green exit. Verified in the CI-equivalent environment (Python 3.14.8 + homeassistant 2026.10.1): HEAD exits 0 with "no Home-Assistant API drift (13 modules, 60 imports, 35 call arguments, 7 awaited HA calls)"; the empty directory exits 1 with 4 FLOOR lines and no findings; a missing path exits 1 with the ``bad-path`` finding; and the full pre-fix tree (``git archive 5ede4fe``) exits 1 with exactly the three t36 drifts (media_player.py:965 BrowseMediaSource, diagnostics.py:93 homeassistant.util.diagnostic, config_flow.py:425 missing-await) and 0 floor violations. The fast ``test`` job and ``release.yml`` are untouched; the workflow is unchanged in shape except the new provisioning + guard steps, and parses as valid YAML.	2026-10-10 21:29:39 +01:00
James Mackay	824d6192a1	test(ci): D1/D2/D3 — repo-owned HA API-drift sweep with a CI job (t37) ... The unit suite validates production modules against hand-written stubs, so a call site that no longer matches real Home Assistant stays green — that is how D1, D2 and D3 reached master. This adds the check that would have caught them. `tests/ha_api_drift.py` (stdlib-only, documented inline) parses every module of custom_components/nvidia_shield and resolves each Home-Assistant dependency against an INSTALLED homeassistant: 1. every `homeassistant.*` import — module present, attribute present (or a submodule of that name exists, which is what `from package import submodule` means) — catches D1/D2 and any future move; 2. every keyword argument passed to a known HA API (HA_CALL_OWNERS: the ConfigFlow/ConfigEntries APIs we call) must exist in the real signature — catches the `options_updates` class of bug; 3. every `self.<method>()` call in a class that inherits from an HA class is compared with the real definition: a coroutine must be awaited and an awaited call must be a coroutine — catches D3. `tests/test_ha_api_drift.py` runs it against the production tree, asserts the sweep is not vacuous (module/import/argument/await counters), and pins the red proof with the four pre-fix forms, plus the green proof for the fixed forms. It skips cleanly when homeassistant is absent, so the stdlib-only jobs are unaffected. `.gitea/workflows/test.yml` gains the `ha-api-drift` job — the one place Home Assistant is installed — guarded by an explicit Python >= 3.13 check (Home Assistant 2026.x requires it) and the same PEP 668 retry the test job uses. Red proof against the real pre-fix revisions (svn-style checkout of `git show HEAD:…` into a temp dir, and the pre-t35 config_flow.py for the kwarg): media_player.py:965: broken-import: from homeassistant.components.media_player import BrowseMediaSource: …BrowseMediaSource does not exist diagnostics.py:93: broken-import: from homeassistant.util.diagnostic import async_redact_data: module 'homeassistant.util.diagnostic' is not importable config_flow.py:425: missing-await: self._async_handle_discovery_without_unique_id() is a coroutine on homeassistant.config_entries.ConfigFlow config_flow.py:700: unknown-kwarg: async_update_reload_and_abort() has no 'options_updates' parameter (exit 1 on that tree, exit 0 on this one) Verified: variant 1 289 passed / 2 skipped; variant 2 (androidtvremote2) 290 passed / 1 skipped; ruff clean; `UV_PYTHON=3.13 uvx --with homeassistant --with pytest-asyncio pytest tests/test_ha_api_drift.py -q` → 4 passed (the bare form of that command needs the pin here only because this sandbox's default Python is 3.15 and pycares has no wheel for it / no CMake to build it; CI pins the interpreter explicitly).	2026-10-10 21:20:28 +01:00
James Mackay	bbd98ebc3f	ci: survive PEP 668 on externally managed runners — retry the test-tooling install with --break-system-packages, pin the gate tool versions	2026-10-10 08:34:34 +01:00
James Mackay	5f8c3290cc	fix: flow VERSION=2 for new entries; optional ENTER gains the ADB keyevent-66 fallback; CI installs androidtvremote2 for the real-library tests (F4, F5, F6)	2026-10-08 10:12:12 +01:00
James Mackay	ce82127a40	ci: add lint+test workflow; schedule package constants (TiviMate/Wholphin/system media); drop the stale sibling-checkout dev dependency	2026-10-08 07:49:07 +01:00