Astroklient zbudował się poprawnie, ale jego obraz nie schodził do klastra.
Przyczyna nie leżała ani w CI, ani w rejestrze: CRD ImageUpdater w klastrze miał
CZTERY obrazy (data, logic, presentation, render), a plik w gicie sześć.
Brakowało astrodemo I astroklienta.
`image-updater.yaml` nie był w kustomization.yaml, więc ArgoCD go nie nakładał.
Dopisanie usługi do pliku nie robiło zatem nic — listy nikt nie stosował.
ODWRACAM DECYZJĘ UDOKUMENTOWANĄ W TYM REPO. README twierdziło, że wyłączenie jest
celowe: resource stoi w ns argocd, poza namespace docelowym aplikacji, i jest
konfiguracją kontrolera, a nie aplikacji. Rozumowanie nie było głupie, ale nie
wytrzymało praktyki — ręczny krok zapomniano dwa razy w ciągu dwóch tygodni,
najpierw dla astrodemo, potem dla astroklienta.
Najgorsza była CICHOŚĆ rozjazdu. Plik w gicie wyglądał poprawnie, git log
pokazywał dopisanie usługi, a objawem był obraz, który „się nie deployuje" — co
kieruje podejrzenia na CI albo na rejestr, czyli wszędzie poza właściwe miejsce.
Diagnoza wymaga porównania pliku ze stanem klastra, a nikt nie porównuje rzeczy,
o której nie wie, że mogą się różnić.
Przeszkody technicznej nie było: projekt ArgoCD dopuszcza dowolną przestrzeń nazw
(destinations: '*'), a dry-run serwerowy przyjmuje resource bez zastrzeżeń.
W README zostaje wyjaśnienie, dlaczego jest w kustomization mimo wcześniejszego
uzasadnienia — razem z prośbą, żeby przy ewentualnym wyjmowaniu usunąć też ten
akapit. Inaczej następna osoba przeczyta powód, którego już nie ma.
Zweryfikowane: kustomize build 38 obiektów (było 37), dry-run serwerowy
aktualizuje istniejący CRD.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea