fix(ci): wyrocznia domów — wbuduj pliki w obraz zamiast montować (-v nie działa)
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m28s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 22s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 9s
build / build (push) Successful in 2m47s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m31s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 3m23s
Testy / Kontrola składni wszystkich warstw (push) Successful in 9s

Krok padał na `python: can't open file '/oracle/run.py'`. Przyczyna jest tą samą
pułapką, którą złapano już wcześniej przy `-p` i localhoście (jest o niej komentarz
w tym samym pliku): job Gitea Actions SAM działa w kontenerze, więc `docker run -v
$PWD/...` demon rozwiązuje na HOŚCIE, gdzie tej ścieżki nie ma. Docker nie zgłasza
wtedy błędu — po cichu tworzy PUSTY katalog, przez co skrypt „znika".

Zamiast montowania wbudowujemy pliki w pomocniczy obraz (FROM engine-swisseph:ci
+ COPY). Kontekst builda jest strumieniowany do demona, więc działa niezależnie od
tego, gdzie ten demon stoi. Obraz kasujemy po użyciu.

Przy okazji .dockerignore: docker NIE czyta .gitignore, więc do demona poleciałby
cały korzeń repo — z lokalnym wirtualenvem (344 MB) i jądrami efemeryd włącznie.
Kontekst spada z 382 MB do 5,9 MB, co na runnerze z historią „no space left on
device" nie jest kosmetyką. Plik dotyczy tylko buildów z korzenia repo — obrazy
usług mają własne konteksty (services/<usługa>) i go nie widzą.

Zweryfikowane bez dockera: sprawdzony dokładny tekst, jaki dostanie powłoka po
dedentacji YAML (terminator heredoca w kolumnie 0), istnienie ścieżek COPY oraz to,
że reguły .dockerignore nie wycinają plików potrzebnych do uruchomienia.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit was merged in pull request #61.
This commit is contained in:
2026-08-04 23:20:43 +02:00
parent 86a0f16f9e
commit 40f5e459e0
2 changed files with 52 additions and 5 deletions
+19 -5
View File
@@ -149,11 +149,25 @@ jobs:
# niż wykryć po fakcie.
- name: Domy — zgodność z wyrocznią (brzegi + wnętrze)
run: |
docker run --rm \
-v "$PWD/services/logic:/logic:ro" \
-v "$PWD/tests/oracle:/oracle:ro" \
-e LOGIC_PATH=/logic \
astrololo/engine-swisseph:ci python /oracle/run.py --mode build
# Pliki WBUDOWUJEMY w obraz, a nie montujemy przez -v. Powód ten sam,
# dla którego wyżej nie startujemy kontenera w tle: job Gitea Actions sam
# działa w kontenerze, więc `-v $PWD/...` docker rozwiązuje na HOŚCIE,
# gdzie tej ścieżki nie ma. Docker nie zgłasza wtedy błędu — po cichu
# tworzy PUSTY katalog, przez co skrypt „znika". Kontekst builda jest
# strumieniowany do demona, więc działa niezależnie od tego, gdzie on stoi.
docker build -t astrololo/oracle:ci -f - . <<'DOCKERFILE'
FROM astrololo/engine-swisseph:ci
COPY services/logic /logic
COPY tests/oracle /oracle
ENV LOGIC_PATH=/logic
DOCKERFILE
docker run --rm astrololo/oracle:ci python /oracle/run.py --mode build
# Obraz pomocniczy nie jest już potrzebny — a runner miał już incydent
# „no space left on device", więc sprzątamy po sobie od razu.
- name: Usuń obraz pomocniczy wyroczni
if: always()
run: docker rmi -f astrololo/oracle:ci 2>/dev/null || true
# Sprzątanie po POPRZEDNICH przebiegach starej wersji workflow, która
# zostawiała kontener „swe" na runnerze i blokowała nazwę. Nowa wersja