2 Commits

Author	SHA1	Message	Date
gitea	cf24c4d473	ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze ... Rejestr obrazów rósł, bo `build.yaml` budował CZTERY obrazy przy każdym pushu do mastera, niezależnie od tego, co się zmieniło. Zmiana w samej prezentacji dawała nowe wersje data, logic i astrodemo — identyczne co do zawartości, różniące się wyłącznie tagiem. Render i silnik B miały filtry ścieżek od początku (build-render.yaml, build-swisseph.yaml) i budują się tylko przy własnych zmianach. Ta zmiana przenosi tę samą zasadę do głównego pipeline'u, licząc różnicę wobec poprzedniego commita. Kontekstem budowania każdego obrazu jest wyłącznie `./services/<nazwa>`, więc porównanie ścieżek jest dokładne, a nie przybliżone. Sprawdzone na ośmiu ostatnich commitach mastera: dwa refaktory prezentacji dają sam `presentation`, poprawka Dockerfile'a astrodemo daje samo `astrodemo`, a commit ruszający link_crypto w pięciu usługach — komplet. Bez porównania (pierwszy commit, przepisana historia) budujemy wszystko: lepiej zbudować za dużo niż wypuścić obraz ze starym kodem pod nowym tagiem. SKUTEK UBOCZNY DO ŚWIADOMOŚCI: tagi w kustomization mogą się teraz rozjechać między usługami, bo nie każda dostaje nową wersję z każdego commita. Tak ma być — image-updater śledzi każdy obraz osobno i przypina to, co istnieje. ZABEZPIECZENIE PRZED CICHYM POMINIĘCIEM. Usługa, której nie ma na żadnej liście, nigdy się nie zbuduje i nikt tego nie zauważy: brak obrazu wygląda potem na problem z rejestrem albo z siecią. Ten sam mechanizm kosztował nas już raz, przy liście obserwowanych obrazów w image-updaterze. Pętla po `services/*/` zatrzymuje budowanie i mówi wprost, co dopisać. Sprawdzone także od strony negatywnej — podstawiony katalog nowej usługi kończy przebieg kodem 1. SPRZĄTANIE NA RUNNERZE, w build.yaml i w build-render.yaml, z `if: always()` — bo to po NIEUDANYM budowaniu zostaje najwięcej śmieci, a kolejny przebieg zaczyna od mniejszego zapasu miejsca niż poprzedni. Tak zatkał się dysk przy renderze z TeX Live. Filtr `until=168h` zostawia tydzień, więc warstwy bazowe i cache przeżywają i build nie zaczyna od zera. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 20:13:27 +02:00
gitea	56131b209a	ci: workflow budujacy obraz uslugi render (PRE-24) ... Luka: usluga render (services/render) weszla w #32, ale zaden workflow nie budowal jej obrazu — wiec astrololo-render:latest nie istnial w rejestrze, a pod zawislby na ImagePullBackOff po wdrozeniu manifestow. Osobny pipeline (jak build-swisseph), nie dopisanie do build.yaml: obraz dzwiga TeX Live (setki MB), a build.yaml chodzi przy KAZDYM pushu do mastera. Budowanie renderu za kazdym razem spowalnialoby kazdy deploy — a to wlasnie ta izolacja miala usunac. Wyzwalany tylko zmiana w services/render/**; workflow_dispatch do bootstrapu. Merge tego PR zbuduje pierwszy obraz (push dotyka pliku workflow, wiec trigger sie odpali) i wypchnie :latest — dopiero potem ma sens merge deploy#5. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 13:30:24 +02:00