Files
astrololo/services/presentation/app
gitea 15964dd0df
build / build (push) Successful in 1m16s
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 11m11s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m40s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 30s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 20s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m38s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m38s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 26s
Testy / Kontrola składni wszystkich warstw (push) Successful in 21s
chore: wymuszenie nowego obrazu data/logic/presentation po incydencie z :latest
Komentarz-marker w main.py każdej z trzech usług — zmienia zawartość obrazu, więc
build.yaml wyprodukuje NOWE SHA-tagi z nowszym `created`. To odblokowuje
image-updatera (strategia newest-build), który utknął: wszystkie trzy usługi mają
w deployu tag `:latest`, którego build.yaml nigdy nie pcha (tylko SHA), więc nowe
pody wpadły w ImagePullBackOff. Nowy build z realnym SHA da updaterowi co promować
i przykryje `:latest` w kustomization — bez ręcznej zmiany w repo deploy.

UWAGA: samo to NIE wystarczy. W namespace astrololo zniknął pull-secret
`gitea-registry`, więc nawet z poprawnym tagiem nowe pody nie pobiorą obrazu.
Trzeba go odtworzyć (kopia działającego `gitea-registry-creds` z ns argocd) —
osobna, ręczna operacja, poza tym commitem.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 16:58:01 +02:00
..