gitea 40f5e459e0 fix(ci): wyrocznia domów — wbuduj pliki w obraz zamiast montować (-v nie działa) ...

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>

2026-08-04 23:20:43 +02:00

..

build-render.yaml

ci: workflow budujacy obraz uslugi render (PRE-24)

2026-07-25 13:30:24 +02:00

build-swisseph.yaml

ci(swisseph): osobny workflow budujacy obraz silnika B

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

build.yaml

tt

2026-07-18 21:57:33 +02:00

tests.yml

fix(ci): wyrocznia domów — wbuduj pliki w obraz zamiast montować (-v nie działa)

2026-08-04 23:20:43 +02:00