astrodemo — wdrożenie wersji demonstracyjnej (PRE-28/29) #24

2026-08-26T13:57:09Z

gitea commented

2026-08-26 13:57:09 +00:00

Zastępuje #19 — tamten PR można zamknąć, i to nie tylko z powodu nazwy.

Dlaczego nie dało się po prostu zmergować #19

Gałąź feat/astroklient była odbita od mastera sprzed jedenastu commitów i miała przypięte obrazy ee3c515d, podczas gdy master stoi na 320a0ab2. Merge w tamtej postaci cofnąłby klaster o kilka wersji — łącznie z sesjami logowania i całą paranoją.

Rebase konfliktował na README.md przy każdym z czterech commitów, więc gałąź jest odtworzona jednym commitem na aktualnym masterze, z zachowanymi tagami obrazów.

Brakowało wejścia z zewnątrz

Manifesty tworzyły Deployment i Service, ale żadnej reguły w Ingressie — usługa wstałaby i nie dałoby się do niej wejść. Dołożony host astrodemo.czernobog.pl z przekierowaniem z http, a tls.yaml obejmuje teraz oba hosty jednym certyfikatem.

Osobny host, a nie ścieżka /demo pod adresem astrololo, celowo: ścieżka dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli i ciasteczka — wejście do jednej ruszałoby sesję w drugiej.

Poprawki w runbooku

Opis twierdził, że demo pracuje na produkcyjnej warstwie danych. Nieprawda od PRE-29 — ma własny stos (astrodemo-stack.yaml) i własny udział.

Zmiana nazw rozjechała przy tym ścieżkę udziału: zfs create Tank1/astrololo-astrodemo przy manifeście montującym /mnt/Tank1/astrololo-demo utworzyłby inny zbiór niż ten, którego pod szuka. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była.

Obraz na liście obserwowanych

Bez wpisu w image-updater.yaml obraz nigdy się nie podbije, choćby CI go budowało. Tak przez chwilę wisiał render na :latest.

Sprawdzone

kubectl kustomize astrololo/ buduje 29 obiektów. Tagi pozostają na 320a0ab2.

Kolejność: ten PR wchodzi po zmergowaniu astrololo#79 — inaczej image-updater nie znajdzie obrazu astrololo-astrodemo (CI zacznie go budować dopiero po tamtym merge'u). Przed wdrożeniem trzeba jeszcze utworzyć udział NFS, sekret astrololo-astrodemo i wpis DNS — kroki w README-astrodemo.md.

**Zastępuje #19** — tamten PR można zamknąć, i to nie tylko z powodu nazwy. ### Dlaczego nie dało się po prostu zmergować #19 Gałąź `feat/astroklient` była odbita od mastera sprzed jedenastu commitów i miała przypięte obrazy **`ee3c515d`**, podczas gdy master stoi na **`320a0ab2`**. Merge w tamtej postaci **cofnąłby klaster o kilka wersji** — łącznie z sesjami logowania i całą paranoją. Rebase konfliktował na `README.md` przy każdym z czterech commitów, więc gałąź jest odtworzona **jednym commitem na aktualnym masterze**, z zachowanymi tagami obrazów. ### Brakowało wejścia z zewnątrz Manifesty tworzyły Deployment i Service, ale **żadnej reguły w Ingressie** — usługa wstałaby i nie dałoby się do niej wejść. Dołożony host `astrodemo.czernobog.pl` z przekierowaniem z http, a `tls.yaml` obejmuje teraz oba hosty jednym certyfikatem. Osobny host, a nie ścieżka `/demo` pod adresem astrololo, **celowo**: ścieżka dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli i ciasteczka — wejście do jednej ruszałoby sesję w drugiej. ### Poprawki w runbooku Opis twierdził, że demo pracuje na **produkcyjnej** warstwie danych. Nieprawda od PRE-29 — ma własny stos (`astrodemo-stack.yaml`) i własny udział. Zmiana nazw rozjechała przy tym ścieżkę udziału: `zfs create Tank1/astrololo-astrodemo` przy manifeście montującym `/mnt/Tank1/astrololo-demo` utworzyłby **inny zbiór niż ten, którego pod szuka**. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była. ### Obraz na liście obserwowanych Bez wpisu w `image-updater.yaml` obraz nigdy się nie podbije, choćby CI go budowało. Tak przez chwilę wisiał render na `:latest`. ### Sprawdzone `kubectl kustomize astrololo/` buduje 29 obiektów. Tagi pozostają na `320a0ab2`. --- **Kolejność:** ten PR wchodzi **po** zmergowaniu astrololo#79 — inaczej image-updater nie znajdzie obrazu `astrololo-astrodemo` (CI zacznie go budować dopiero po tamtym merge'u). Przed wdrożeniem trzeba jeszcze utworzyć udział NFS, sekret `astrololo-astrodemo` i wpis DNS — kroki w [README-astrodemo.md](astrololo/README-astrodemo.md).

gitea added 2 commits 2026-08-26 17:50:53 +00:00

astrodemo: wdrożenie wersji demonstracyjnej (PRE-28/29) 1d5bd27cdc

Zastępuje gałąź feat/astroklient. Tamta była odbita od mastera sprzed jedenastu
commitów i miała przypięte obrazy `ee3c515d`, podczas gdy master stoi na
`320a0ab2` — merge w tamtej postaci COFNĄŁBY klaster o kilka wersji. Zamiast
przepychać cztery commity przez rebase (każdy konfliktował na README), gałąź
jest odtworzona jednym commitem na aktualnym masterze, z zachowanymi tagami.

ZMIANA NAZWY. astroklient-demo → astrodemo, wraz z nazwą obrazu, zmiennymi
(ASTRODEMO_USERS) i sekretem (astrololo-astrodemo). Nazwa „astroklient" jest
zarezerwowana dla warstwy pośredniej: pełne funkcje astrologiczne, bez
generowania tekstu i bez administracji.

BRAKOWAŁO WEJŚCIA Z ZEWNĄTRZ. Manifesty tworzyły Deployment i Service, ale żadnej
reguły w Ingressie — usługa wstałaby i nie dałoby się do niej wejść. Dołożony
host astrodemo.czernobog.pl z przekierowaniem z http, a certyfikat obejmuje teraz
oba hosty.

Osobny host, a nie ścieżka `/demo` pod adresem astrololo, CELOWO: ścieżka
dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli
i ciasteczka — wejście do jednej ruszałoby sesję w drugiej.

OBRAZ NA LIŚCIE OBSERWOWANYCH. Bez wpisu w image-updater.yaml obraz nigdy się nie
podbije, choćby CI go budowało. Tak przez chwilę wisiał render na :latest.

POPRAWKI W RUNBOOKU. Opis twierdził, że demo pracuje na produkcyjnej warstwie
danych — nieprawda od PRE-29, ma własny stos i własny udział. Ponadto zmiana nazw
rozjechała ścieżkę udziału: `zfs create Tank1/astrololo-astrodemo` przy manifeście
montującym `/mnt/Tank1/astrololo-demo` utworzyłby inny zbiór niż ten, którego pod
szuka. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była.

Sprawdzone: `kubectl kustomize astrololo/` buduje 29 obiektów, tagi obrazów
pozostają na 320a0ab2.

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

astrodemo: ostrzeżenie o tagu obrazu przed pierwszym wdrożeniem 17aa73c562

CI pcha obrazy wyłącznie pod tagiem ośmioznakowym i NIGDY nie pcha `latest`,
a manifest demo wskazywał `latest`. Pod zatrzymałby się na ImagePullBackOff —
objaw wygląda na problem z rejestrem albo z siecią, a jest zwykłym brakiem tagu.

Pozostałe usługi tego nie pokazują, bo image-updater dawno podmienił im tagi na
SHA. Nowa usługa startuje od zera i nie ma czego podmienić.

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

gitea force-pushed feat/astrodemo from b4fe5fbffa to 17aa73c562

2026-08-26 17:50:53 +00:00

Compare

gitea merged commit 17aa73c562 into master

2026-08-26 17:51:22 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/deploy#24