glenn schrooyenandClaude Opus 5
9c1a23328a
checks / unit (pull_request) Successful in 2m39s
Before this commit `admin/goodwe-addon` had no `.gitea/workflows/` directory at all. Eight runnable test files - `test_loop.py` alone drives the real `run_control()` for 93 s of wall clock - and not one of them had ever been run by a machine. Every merge here was a human reading a diff, and the product owner's requirement that a green CI gate a merge could not be met on a repository with no CI to be green. One job, `unit`, with no `paths:` filter, so it reports on every PR and can therefore be a REQUIRED status check: Gitea leaves a required context it never receives pending forever, which is the failure mode on the other side of this ticket. Concurrency is scoped per PR from the start rather than to a bare group name - the bare name is what let the infra repo's run 521 be superseded while still pending, so its four jobs concluded `cancelled` with `started_at` at the Unix epoch and its PR merged on no evidence at all. The tests run in `.gitea/ci/Dockerfile`: `alpine:3` plus `py3-aiohttp` and `py3-paho-mqtt` from apk, matching goodwe_controller/Dockerfile exactly, because pip would install glibc wheels of a library the shipped image gets from Alpine. The runner itself cannot host them - bare python3, no aiohttp, no pip - and mutating a shared long-lived runner with `apk add` is invisible to anyone reading this repo. Two things measured while building it and recorded in the file rather than learned again: the checkout must sit two levels below the mount root or test_freeze.py's `find_hwsim()` dies on `IndexError: 1` before its first assertion, and test_freeze's hwsim section is silently absent here because admin/goodwe is private - so its PASS is a weaker claim than it looks, and the file says so. Verified green on release/1.0 content before this workflow was written: 8 of 8 files pass, ~4 minutes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC
23 lines
1.4 KiB
Docker
23 lines
1.4 KiB
Docker
# The image the add-on's tests run in (CI-01). This repo had NO CI at all before
|
|
# that ticket - eight runnable test files, none of them ever run by a machine.
|
|
#
|
|
# ⚠️ THE DEPENDENCIES ARE THE SHIPPED ONES, FROM APK, AND THAT IS THE POINT.
|
|
# goodwe_controller/Dockerfile installs `py3-aiohttp py3-paho-mqtt` from Alpine
|
|
# packages rather than pip, because Alpine ships musl and there are no musl
|
|
# wheels for aiohttp - pip would compile it from source on a client's Raspberry
|
|
# Pi. Testing against pip-installed glibc wheels would be testing a different
|
|
# add-on from the one that ships. Same base, same package manager, same names.
|
|
#
|
|
# ⚠️ NOT `FROM ghcr.io/home-assistant/...-base`. The real Dockerfile takes its
|
|
# base from the Supervisor's `BUILD_FROM` build-arg, which is per-architecture
|
|
# and not resolvable outside a Supervisor build. `alpine:3` is what those images
|
|
# are, minus the s6 supervision the tests do not use - and it is already cached
|
|
# on this runner's host, so the gate does not depend on a registry pull.
|
|
#
|
|
# ⚠️ The runner container itself CANNOT run these tests: it is Alpine with a bare
|
|
# python3, no aiohttp, no pip (`No module named pip`; checked on the box, not
|
|
# assumed). An image is not gold-plating here, it is the only option that does
|
|
# not mutate a shared long-lived runner.
|
|
FROM alpine:3
|
|
RUN apk add --no-cache python3 py3-aiohttp py3-paho-mqtt
|