chore(astrololo): manifest CRD image-updater w repo #6

2026-07-25T22:03:12Z

gitea commented

2026-07-25 22:03:12 +00:00

Po co

Konfiguracja argocd-image-updater dla astrololo żyła wyłącznie w klastrze
(ręczny kubectl apply, brak w git). Nie dało się jej podejrzeć ani odtworzyć —
i właśnie dlatego render (PRE-24) przez chwilę nie schodził na klaster: usługa
budowała tag SHA, ale nie było jej na jawnej liście obserwowanych obrazów CRD,
więc updater jej nie ruszał. Objaw: 3 obrazy skaczą na SHA, render wisi na latest.

Co jest w PR

astrololo/image-updater.yaml — manifest CRD ImageUpdater (ns argocd),
już z czterema obrazami: data / logic / presentation / render.
astrololo/README.md — sekcja „Co śledzi image-updater": jak dodać nową usługę
do rotacji i dlaczego pliku nie ma w kustomization.yaml.

Świadoma decyzja: NIE w kustomization.yaml

Resource stoi w ns argocd, a Application astrololo celuje w ns astrololo —
auto-sync przez kustomize próbowałby zapisać poza swój namespace docelowy. Poza tym
to konfiguracja kontrolera, który wdraża tę właśnie aplikację; niech app nie
zarządza narzędziem, które ją wdraża. Dlatego: plik w repo dla odtwarzalności,
nakładany ręcznie:

kubectl apply -f astrololo/image-updater.yaml

Stan w klastrze

Manifest odzwierciedla to, co już działa: imagesManaged: 4, render na liście
(dopisany wcześniej patchem). PR domyka lukę „to, co śledzimy, żyje tylko w klastrze".

## Po co Konfiguracja **argocd-image-updater** dla astrololo żyła wyłącznie w klastrze (ręczny `kubectl apply`, brak w git). Nie dało się jej podejrzeć ani odtworzyć — i właśnie dlatego `render` (PRE-24) przez chwilę nie schodził na klaster: usługa budowała tag SHA, ale **nie było jej na jawnej liście** obserwowanych obrazów CRD, więc updater jej nie ruszał. Objaw: 3 obrazy skaczą na SHA, `render` wisi na `latest`. ## Co jest w PR - `astrololo/image-updater.yaml` — manifest CRD `ImageUpdater` (ns `argocd`), już z **czterema** obrazami: `data` / `logic` / `presentation` / **`render`**. - `astrololo/README.md` — sekcja „Co śledzi image-updater": jak dodać nową usługę do rotacji i dlaczego pliku nie ma w `kustomization.yaml`. ## Świadoma decyzja: NIE w kustomization.yaml Resource stoi w ns `argocd`, a Application astrololo celuje w ns `astrololo` — auto-sync przez kustomize próbowałby zapisać poza swój namespace docelowy. Poza tym to konfiguracja kontrolera, który wdraża **tę właśnie** aplikację; niech app nie zarządza narzędziem, które ją wdraża. Dlatego: plik w repo dla odtwarzalności, nakładany **ręcznie**: ```bash kubectl apply -f astrololo/image-updater.yaml ``` ## Stan w klastrze Manifest odzwierciedla to, co już działa: `imagesManaged: 4`, `render` na liście (dopisany wcześniej patchem). PR domyka lukę „to, co śledzimy, żyje tylko w klastrze".

gitea added 1 commit 2026-07-25 22:03:12 +00:00

chore(astrololo): manifest CRD image-updater w repo (ślad tego, co śledzimy) 3df1170f5d

Konfiguracja argocd-image-updater istniała tylko w klastrze (ręczne `kubectl
apply`, brak w git). Skutkiem był PRE-24: `render` zbudował się i zdeployował raz,
ale kolejne buildy nie schodziły — bo nie było go na JAWNEJ liście obserwowanych
obrazów CRD, a nigdzie nie dało się tego podejrzeć ani odtworzyć.

Zrzucam manifest (z `render` już w środku, 4 obrazy: data/logic/presentation/
render) do `astrololo/image-updater.yaml` + opis w README.

Plik CELOWO nie jest w kustomization.yaml: resource stoi w ns `argocd` (poza
namespace docelowym aplikacji), a to konfiguracja kontrolera wdrażającego tę
aplikację — nakładany ręcznie (`kubectl apply -f astrololo/image-updater.yaml`),
w repo dla odtwarzalności i historii. Dodanie nowej usługi = dopisanie wpisu tutaj.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

gitea merged commit 3df1170f5d into master

2026-07-25 22:05:08 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/deploy#6