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>
