chore: wymuszenie nowego obrazu (odblokowanie rollout po :latest) #35

Merged

gitea merged 1 commits from chore/force-rebuild into master 2026-07-25 15:04:09 +00:00

Conversation 0 Commits 1 Files Changed 3

+3

gitea commented 2026-07-25 14:58:21 +00:00

Owner

Copy Link

Copy Source

Marker-komentarz w main.py trzech usług (data/logic/presentation) — zmienia
zawartość obrazu, więc build.yaml wyprodukuje nowe SHA-tagi z nowszym
created. To odblokowuje image-updatera (strategia newest-build), który utknął,
bo w deployu wszystkie trzy usługi mają tag :latest — którego build.yaml nigdy
nie pcha (tylko SHA) → nowe pody w ImagePullBackOff.

Nowy build z realnym SHA da updaterowi co promować i przykryje :latest
w kustomization, bez ręcznej zmiany w repo deploy.

⚠️ Sam ten PR nie wystarczy — dwa warunki

1. Pull-secret gitea-registry zniknął z namespace astrololo. Bez niego nowe
   pody nie pobiorą żadnego obrazu, nawet z poprawnym tagiem. Odtworzenie (poza
   tym PR, ręcznie) — komenda w opisie mojej odpowiedzi.
2. Merge tego PR odpala build.yaml (push na master) → nowe obrazy.

Dopiero po obu: image-updater promuje nowy SHA → rollout rusza → nowy pod
presentation startuje z LINK_KEY_PRESENTATION_RENDER → znika 500 na
/compile/pdf.

Testy: logika 265/1 skip, prezentacja 131 (marker to komentarz, nic nie rusza).

Marker-komentarz w `main.py` trzech usług (data/logic/presentation) — zmienia zawartość obrazu, więc `build.yaml` wyprodukuje **nowe SHA-tagi** z nowszym `created`. To odblokowuje image-updatera (strategia `newest-build`), który utknął, bo w deployu wszystkie trzy usługi mają tag `:latest` — którego `build.yaml` nigdy nie pcha (tylko SHA) → nowe pody w ImagePullBackOff. Nowy build z realnym SHA da updaterowi co promować i **przykryje `:latest`** w kustomization, bez ręcznej zmiany w repo `deploy`. ## ⚠️ Sam ten PR nie wystarczy — dwa warunki 1. **Pull-secret `gitea-registry` zniknął** z namespace `astrololo`. Bez niego nowe pody nie pobiorą żadnego obrazu, nawet z poprawnym tagiem. Odtworzenie (poza tym PR, ręcznie) — komenda w opisie mojej odpowiedzi. 2. **Merge tego PR** odpala `build.yaml` (push na master) → nowe obrazy. Dopiero po obu: image-updater promuje nowy SHA → rollout rusza → nowy pod presentation startuje **z** `LINK_KEY_PRESENTATION_RENDER` → znika 500 na `/compile/pdf`. Testy: logika 265/1 skip, prezentacja 131 (marker to komentarz, nic nie rusza).

gitea added 1 commit 2026-07-25 14:58:21 +00:00

chore: wymuszenie nowego obrazu data/logic/presentation po incydencie z :latest ... 15964dd0df

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>

gitea merged commit 15964dd0df into master 2026-07-25 15:04:09 +00:00

gitea deleted branch chore/force-rebuild 2026-07-25 15:04:10 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

gitea

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/astrololo#35