ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze #82

Merged

gitea merged 1 commits from fix/ci-buduj-tylko-zmienione into master 2026-08-26 18:21:16 +00:00

Conversation 0 Commits 1 Files Changed 2

+90 -4

gitea commented 2026-08-26 18:13:28 +00:00

Owner

Copy Link

Copy Source

Odpowiedź na puchnący rejestr obrazów — ale najpierw zmierzyłem, bo liczby wyszły inne, niż się spodziewałem.

Co pokazał pomiar

65 wersji, 12,85 GB — ale to licząc warstwy wielokrotnie. Kolejne wersje tej samej usługi dzielą warstwę bazową i warstwę zależności, więc realne zajęcie jest wyraźnie niższe. Astrololo trzyma się szczupło (0,06–0,16 GB na usługę); największy pojedynczy obraz to conjurer-bot (0,71 GB).

Prawdziwym motorem przyrostu było co innego: build.yaml budował cztery obrazy przy każdym pushu, 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.

Co się zmienia

Główny pipeline liczy różnicę wobec poprzedniego commita i buduje tylko to, co jej dotyczy. Render i silnik B miały filtry ścieżek od początku — to przeniesienie tej samej zasady do reszty.

Sprawdzone na ośmiu ostatnich commitach mastera:

commit	buduje
fd79513 ekrany jako moduły	presentation
62d6f9d AI jako moduł	presentation
10ade55 Dockerfile astrodemo	astrodemo
2e9d370 zmiana nazwy + link_crypto w 5 usługach	komplet

Bez punktu odniesienia (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.yaml mogą się teraz rozjechać między usługami. Tak ma być — image-updater śledzi każdy obraz osobno.

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 też od strony negatywnej: podstawiony katalog nowej usługi kończy przebieg kodem 1.

Sprzątanie na runnerze

W build.yaml i 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. Dokładnie 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.

---

Czego ten PR NIE załatwia. Kilka GB w rejestrze to za mało na „ponad rozsądek", więc podejrzewam, że miejsce zżera co innego — logi i artefakty Gitea Actions albo cache Dockera na runnerze. Gitea stoi poza klastrem, więc nie zmierzę jej dysku. Warto sprawdzić u źródła du -sh /var/lib/gitea/data/* i docker system df na runnerze.

Osobno warto ustawić regułę retencji w Gitei (Packages → Cleanup Rules): „zachowaj 5 najnowszych", nie „starsze niż X dni" — reguła po dacie skasowałaby astrololo-render:latest z 5 sierpnia, który jest wdrożony.

Odpowiedź na puchnący rejestr obrazów — ale najpierw zmierzyłem, bo liczby wyszły inne, niż się spodziewałem. ### Co pokazał pomiar **65 wersji, 12,85 GB** — ale to licząc warstwy wielokrotnie. Kolejne wersje tej samej usługi dzielą warstwę bazową i warstwę zależności, więc realne zajęcie jest wyraźnie niższe. Astrololo trzyma się szczupło (0,06–0,16 GB na usługę); największy pojedynczy obraz to `conjurer-bot` (0,71 GB). Prawdziwym motorem przyrostu było co innego: **`build.yaml` budował cztery obrazy przy każdym pushu**, 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. ### Co się zmienia Główny pipeline liczy różnicę wobec poprzedniego commita i buduje tylko to, co jej dotyczy. Render i silnik B miały filtry ścieżek od początku — to przeniesienie tej samej zasady do reszty. Sprawdzone na ośmiu ostatnich commitach mastera: | commit | buduje | |---|---| | `fd79513` ekrany jako moduły | `presentation` | | `62d6f9d` AI jako moduł | `presentation` | | `10ade55` Dockerfile astrodemo | `astrodemo` | | `2e9d370` zmiana nazwy + link_crypto w 5 usługach | komplet | Bez punktu odniesienia (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.yaml` mogą się teraz rozjechać między usługami. Tak ma być — image-updater śledzi każdy obraz osobno. ### 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 też od strony negatywnej: podstawiony katalog nowej usługi kończy przebieg kodem 1. ### Sprzątanie na runnerze W `build.yaml` i `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. Dokładnie 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. --- **Czego ten PR NIE załatwia.** Kilka GB w rejestrze to za mało na „ponad rozsądek", więc podejrzewam, że miejsce zżera co innego — logi i artefakty Gitea Actions albo cache Dockera na runnerze. Gitea stoi poza klastrem, więc nie zmierzę jej dysku. Warto sprawdzić u źródła `du -sh /var/lib/gitea/data/*` i `docker system df` na runnerze. Osobno warto ustawić regułę retencji w Gitei (Packages → Cleanup Rules): **„zachowaj 5 najnowszych"**, nie „starsze niż X dni" — reguła po dacie skasowałaby `astrololo-render:latest` z 5 sierpnia, który jest wdrożony.

gitea added 1 commit 2026-08-26 18:13:28 +00:00

ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze ... cf24c4d473

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>

gitea merged commit cf24c4d473 into master 2026-08-26 18:21:16 +00:00

gitea deleted branch fix/ci-buduj-tylko-zmienione 2026-08-26 18:21:16 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

gitea

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/astrololo#82