Files
astrololo/.dockerignore
gitea 40f5e459e0
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
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

34 lines
728 B
Plaintext

# Kontekst builda dla obrazów budowanych z KORZENIA repo (dziś: pomocniczy obraz
# wyroczni w CI — patrz .gitea/workflows/tests.yml). Obrazy usług mają własne
# konteksty (services/<usługa>), więc ten plik ich nie dotyczy.
#
# UWAGA: docker NIE czyta .gitignore. Bez tego pliku do demona poleciałby m.in.
# lokalny wirtualenv (~344 MB) i jądra efemeryd — a runner miał już incydent
# „no space left on device".
# środowiska lokalne
.env/
.venv/
venv/
# cache Pythona i narzędzi
__pycache__/
*.pyc
*.pyo
.pytest_cache/
.ruff_cache/
.mypy_cache/
# dane generowane/pobierane, odtwarzalne
**/.ephemeris/
**/.cache/
# historia i metadane repo
.git/
.gitea/
.claude/
# rzeczy nieużywane w obrazach
docs/
*.md