mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-11-02 18:17:11 +09:00
Juan DenisandClaude Opus 5
4e80d0655f
Seven distro images were green throughout issue #99 because every one of them runs the unit suites against STUBS. That is the right trade for logic, but it left the one thing that talks to real package repos completely untested — so a new Debian release dropping the Python we ask for could only ever be found by a user. scripts/test/test_provision_python.sh runs identify_system, choose_pkg_manager and provision_python for real, then proves the result is usable: in range, can create a virtualenv, has working pip, and imports ssl/sqlite3/ctypes. It needs no systemd, nginx or ports, so it fits the plain containers the matrix already pulls. Reaching the source build counts as a FAILURE, not a pass: a distro that gets there is one we have not really added support for. Wired up as a new `python-provisioning` job over the same images, and debian:13 added to both matrices. Adding trixie to the existing matrix alone would have been decorative — those legs would have gone green on a distro that cannot install. Proven in both directions before being relied on: against the pre-fix tree it reproduced #99 exactly on debian:13 (the reporter's apt errors, the fall through to a source build, and the abort message), while debian:12 passed 7/7. Also fixed the suite pinning the bug. T2 asserted `ver_in_range 3.13` must be FALSE and T1's stub used 3.13 as its "too new" case, so the gate could not be widened without the tests failing. Both moved to 3.14, plus a direct guard on PYTHON_MAX — otherwise a regression to 3.12 could be "fixed" by editing the assertion to match. 122 passed, 0 failed. full-stack-test.ps1 documents why debian13 is NOT in the VM harness: no trixie box publishes a Hyper-V provider (generic/debian13 does not exist, debian/trixie64 is libvirt-only, bento/debian-13 has no hyperv) and Multipass is Ubuntu-only. Named there with what remains uncovered on trixie — the full systemd + nginx + API end-to-end — rather than left as a silent gap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>