gitea
f2ea8e26c0
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>