pyswisseph to rozszerzenie C, a na PyPI (2.10.3.2) gotowe wheels koncza sie
na cp311 i obejmuja wylacznie i686/x86_64. Obraz stoi na python:3.12-slim,
wiec pip ZAWSZE kompilowal ze zrodel - a slim nie ma kompilatora. Stad fail.
- Dockerfile wieloetapowy: kompilacja w etapie builder (build-essential),
do runtime trafia juz tylko gotowy wheel - obraz zostaje czysty i maly.
Dziala tez na arm64, gdzie wheeli linuksowych nie ma dla zadnej wersji.
- sanity check (import swisseph) na etapie builda, zeby niedzialajacy silnik
wywracal build, a nie dopiero pierwszy request.
- CI: nowy job swisseph-image - realny docker build + smoke test /health
i /positions na horoskopie referencyjnym.
- README: udokumentowany powod wieloetapowego builda.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pierwszy run CI dał 59 passed / 20 skipped zamiast 78/1: auto-pobranie jądra
przez Skyfield nie powiodło się na runnerze, więc testy referencyjne (walidacja
względem astro.com) cicho znikały.
- workflow: jawne pobranie de421.bsp curlem z ssd.jpl.nasa.gov (naif zwraca 404),
z retry; EPHEMERIS_DIR wskazany explicite; pytest z -rs (widoczne powody skipów).
- conftest: gdy CI=true, niedostępny silnik kończy się pytest.fail zamiast skip —
żeby utrata pokrycia nigdy więcej nie przeszła niezauważona. Lokalnie (dev bez
pobranego jądra) nadal łagodny skip.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
.github/workflows/tests.yml:
- job "Testy warstwy logicznej": Python 3.12 (jak w obrazach Dockera),
instalacja requirements-dev, pytest na services/logic/tests. Cache pip oraz
cache jądra efemeryd JPL (de421.bsp ~17 MB), by nie pobierać go co run.
- job "Kontrola składni": compileall na wszystkich warstwach (bez instalowania
zależności, w tym AGPL-owego silnika swisseph).
- Triggery: każdy push (dowolna gałąź) + pull requesty do master.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea