fix(swisseph): naprawa builda obrazu silnika B #3

2026-07-20T18:30:39Z

gitea commented

2026-07-20 18:30:39 +00:00

Problem

Kontener engine-swisseph sie nie budowal.

Przyczyna (ustalona, nie zgadnieta)

pyswisseph to rozszerzenie C. Na PyPI w najnowszym wydaniu 2.10.3.2:

tag	wheels linuksowe
cp311	4
cp312	0
cp313	0

Zero wheeli dla cp312 - a obraz stoi na python:3.12-slim. Pip musial wiec
kompilowac ze zrodel, a -slim nie ma kompilatora. Dodatkowo wheels linuksowe
istnieja tylko dla i686/x86_64, wiec na arm64 kompilacja jest konieczna
niezaleznie od wersji Pythona.

Potwierdzenie: pip install pyswisseph na Pythonie 3.14 (gdzie wheela tez nie ma)
konczy sie Successfully built pyswisseph - czyli sdist kompiluje sie bez zarzutu,
brakowalo wylacznie toolchaina w obrazie.

Rozwiazanie

Dockerfile wieloetapowy: kompilacja w etapie builder z build-essential,
do obrazu finalnego wchodzi juz tylko gotowy wheel - runtime zostaje czysty,
bez kompilatora. Rozwazalem prostsze zejscie na python:3.11-slim (gotowy wheel,
zero kompilacji), ale wtedy zostajemy z 3.11 i tak czy siak sypie sie na arm64.
Multi-stage dziala wszedzie i trzyma parytet wersji z reszta uslug.

Do tego sanity check import swisseph na etapie builda - niedzialajacy silnik ma
wywracac build, a nie dopiero pierwszy request.

Weryfikacja

Lokalnie nie ma czym zbudowac: jest klient docker, ale zadnego runtime
(brak Docker.app, colimy, podmana) - docker info pada. Dlatego weryfikacja idzie
przez CI: nowy job swisseph-image robi realny docker build, startuje
kontener i uderza w /health oraz /positions na horoskopie referencyjnym
(30.04.1984). Jak cos padnie, dorzuca docker logs.

Uwaga: jesli runner Gitei nie ma dostepu do dockera, ten job zgasnie z powodow
srodowiskowych, nie kodu - wtedy najprostsza weryfikacja to na Twoim Proxmoxie:
docker compose --profile comparison build engine-swisseph

Co to odblokowuje

Pierwsze realne uruchomienie porownania dwoch silnikow (LOG-25/26) - /chart/compare
i testy parytetu silnika B nigdy jeszcze nie chodzily na zywym swissephie.

Licencja

Bez zmian. Usluga zostaje wydzielona i AGPL-3.0, izolacja procesowa nienaruszona.

## Problem Kontener `engine-swisseph` sie nie budowal. ## Przyczyna (ustalona, nie zgadnieta) `pyswisseph` to rozszerzenie C. Na PyPI w najnowszym wydaniu **2.10.3.2**: | tag | wheels linuksowe | |---|---| | cp311 | 4 | | **cp312** | **0** | | cp313 | 0 | Zero wheeli dla cp312 - a obraz stoi na `python:3.12-slim`. Pip musial wiec kompilowac ze zrodel, a `-slim` nie ma kompilatora. Dodatkowo wheels linuksowe istnieja tylko dla i686/x86_64, wiec na arm64 kompilacja jest konieczna niezaleznie od wersji Pythona. Potwierdzenie: `pip install pyswisseph` na Pythonie 3.14 (gdzie wheela tez nie ma) konczy sie `Successfully built pyswisseph` - czyli sdist kompiluje sie bez zarzutu, brakowalo wylacznie toolchaina w obrazie. ## Rozwiazanie Dockerfile **wieloetapowy**: kompilacja w etapie `builder` z `build-essential`, do obrazu finalnego wchodzi juz tylko gotowy wheel - runtime zostaje czysty, bez kompilatora. Rozwazalem prostsze zejscie na `python:3.11-slim` (gotowy wheel, zero kompilacji), ale wtedy zostajemy z 3.11 i tak czy siak sypie sie na arm64. Multi-stage dziala wszedzie i trzyma parytet wersji z reszta uslug. Do tego sanity check `import swisseph` na etapie builda - niedzialajacy silnik ma wywracac build, a nie dopiero pierwszy request. ## Weryfikacja Lokalnie **nie ma czym** zbudowac: jest klient `docker`, ale zadnego runtime (brak Docker.app, colimy, podmana) - `docker info` pada. Dlatego weryfikacja idzie przez CI: nowy job **`swisseph-image`** robi realny `docker build`, startuje kontener i uderza w `/health` oraz `/positions` na horoskopie referencyjnym (30.04.1984). Jak cos padnie, dorzuca `docker logs`. **Uwaga:** jesli runner Gitei nie ma dostepu do dockera, ten job zgasnie z powodow srodowiskowych, nie kodu - wtedy najprostsza weryfikacja to na Twoim Proxmoxie: `docker compose --profile comparison build engine-swisseph` ## Co to odblokowuje Pierwsze realne uruchomienie **porownania dwoch silnikow** (LOG-25/26) - `/chart/compare` i testy parytetu silnika B nigdy jeszcze nie chodzily na zywym swissephie. ## Licencja Bez zmian. Usluga zostaje wydzielona i AGPL-3.0, izolacja procesowa nienaruszona.

gitea added 1 commit 2026-07-20 18:30:39 +00:00

fix(swisseph): naprawa builda obrazu silnika B

build / build (push) Successful in 43s

Details

85e9182f12

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>

gitea merged commit 85e9182f12 into master

2026-07-20 18:40:43 +00:00

gitea deleted branch fix/swisseph-build

2026-07-20 18:40:43 +00:00

gitea referenced this issue from a commit

2026-07-20 23:55:34 +00:00

ci(swisseph): osobny workflow budujacy obraz silnika B

gitea referenced this pull request

2026-07-20 23:56:16 +00:00

ci(swisseph): workflow budujacy obraz silnika B #4

gitea referenced this issue from a commit

2026-07-21 00:10:58 +00:00