image-updater: definicja wdrażana przez ArgoCD zamiast wklepywanej ręcznie #27

2026-08-27T19:18:47Z

gitea commented

2026-08-27 19:18:47 +00:00

Astroklient zbudował się poprawnie, ale jego obraz nie schodził do klastra. Przyczyna nie leżała ani w CI, ani w rejestrze.

Co znalazłem

Definicja ImageUpdater w klastrze miała cztery obrazy. Plik w gicie ma sześć.

	w gicie	w klastrze
data, logic, presentation, render	✅	✅
astrodemo	✅	❌
astroklient	✅	❌

Skutek — dwie usługi stały na starych obrazach mimo działającego CI:

usługa	biegnie	dostępne
astroklient	`10970c57`	`338ec24e`
astrodemo	`fd79513c`	`10970c57`

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.

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. Jeśli uważasz inaczej, odrzuć ten PR; wtedy alternatywą jest kontrola porównująca plik ze stanem klastra, bo sam runbook już zawiódł.

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. Nikt nie porównuje rzeczy, o której nie wie, że mogą się różnić.

Przeszkody technicznej nie ma: projekt ArgoCD dopuszcza dowolną przestrzeń nazw (destinations: [{namespace: "*", server: "*"}]).

W README zostaje wyjaśnienie 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 → imageupdater.../astrololo configured.

Natychmiastowe odblokowanie, bez czekania na merge

kubectl apply -f astrololo/image-updater.yaml

Astroklient zbudował się poprawnie, ale jego obraz nie schodził do klastra. Przyczyna nie leżała ani w CI, ani w rejestrze. ## Co znalazłem Definicja `ImageUpdater` **w klastrze** miała cztery obrazy. Plik w gicie ma sześć. | | w gicie | w klastrze | |---|---|---| | data, logic, presentation, render | ✅ | ✅ | | **astrodemo** | ✅ | ❌ | | **astroklient** | ✅ | ❌ | Skutek — dwie usługi stały na starych obrazach mimo działającego CI: | usługa | biegnie | dostępne | |---|---|---| | astroklient | `10970c57` | **`338ec24e`** | | astrodemo | `fd79513c` | **`10970c57`** | `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**. ## 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**. Jeśli uważasz inaczej, odrzuć ten PR; wtedy alternatywą jest kontrola porównująca plik ze stanem klastra, bo sam runbook już zawiódł. 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. Nikt nie porównuje rzeczy, o której nie wie, że mogą się różnić. Przeszkody technicznej nie ma: projekt ArgoCD dopuszcza dowolną przestrzeń nazw (`destinations: [{namespace: "*", server: "*"}]`). W README zostaje wyjaśnienie 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 → `imageupdater.../astrololo configured`. ## Natychmiastowe odblokowanie, bez czekania na merge ```bash kubectl apply -f astrololo/image-updater.yaml ```

gitea added 1 commit 2026-08-27 19:18:47 +00:00

image-updater: definicja wdrażana przez ArgoCD zamiast wklepywanej ręcznie 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>

gitea merged commit f2ea8e26c0 into master

2026-08-27 19:31:31 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/deploy#27