gitea/deploy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

astroklient-demo — wdrożenie wersji demonstracyjnej (PRE-28/29) #19

Closed
gitea wants to merge 4 commits from feat/astroklient into master
pull from: feat/astroklient
merge into: gitea:master
Conversation 0 Commits 4 Files Changed 6
+413
gitea commented 2026-08-17 16:40:28 +00:00
Owner
Copy Link
Copy Source

Deployment + Service (ClusterIP), wpięcie w kustomization, obraz w image-updaterze i runbook.

Co musisz zrobić

Jedna komenda — sekret astrololo-demo z hasłem (krok 1 runbooka README-astroklient.md). Osobny, nie astrololo-auth, żeby demo dało się odciąć bez ruszania kont głównej aplikacji.

Do wejścia z zewnątrz trzeba jeszcze dopisać regułę w ingress.yaml — osobny host albo ścieżka, zależnie od tego, jak chcesz demo udostępniać. Celowo tego nie zakładam za Ciebie, bo to decyzja o tym, pod jakim adresem świat zobaczy demo.

Decyzje w manifeście
obraz od razu w image-updaterze obraz, którego tam nie ma, nigdy się nie podbije — tak wisiał render na :latest
token i klucz łącza z tych samych sekretów co prezentacja demo nie jest furtką omijającą ochronę warstwy logicznej
hasło z osobnego sekretu astrololo-demo odcięcie demo = skasowanie jednego sekretu
RATE_LIMIT_PER_MIN: 60 (niżej niż w aplikacji) demo bywa udostępniane szerzej, a każde zapytanie sięga do treści baz
ClusterIP wejście wyłącznie przez Ingress po https, jak prezentacja

⚠️ Runbook zaczyna się od ostrzeżenia

Bo to jedyna rzecz, którą trzeba pamiętać za każdym razem: demo pracuje na produkcyjnej warstwie danych. Kto dostaje adres, czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Pełna izolacja wymagałaby osobnej warstwy danych i nie jest dziś zrobiona.

Zależność: PR aplikacji feat/astroklient — mergować przed albo razem (inaczej nie ma obrazu).

🤖 Generated with Claude Code

Deployment + Service (ClusterIP), wpięcie w `kustomization`, obraz w image-updaterze i runbook. ## Co musisz zrobić **Jedna komenda** — sekret `astrololo-demo` z hasłem (krok 1 runbooka [`README-astroklient.md`](astrololo/README-astroklient.md)). Osobny, nie `astrololo-auth`, żeby demo dało się odciąć bez ruszania kont głównej aplikacji. Do wejścia z zewnątrz trzeba jeszcze dopisać regułę w `ingress.yaml` — osobny host albo ścieżka, zależnie od tego, jak chcesz demo udostępniać. **Celowo tego nie zakładam za Ciebie**, bo to decyzja o tym, pod jakim adresem świat zobaczy demo. ## Decyzje w manifeście | | | |---|---| | obraz **od razu w image-updaterze** | obraz, którego tam nie ma, nigdy się nie podbije — tak wisiał render na `:latest` | | token i klucz łącza z **tych samych** sekretów co prezentacja | demo nie jest furtką omijającą ochronę warstwy logicznej | | hasło z **osobnego** sekretu `astrololo-demo` | odcięcie demo = skasowanie jednego sekretu | | `RATE_LIMIT_PER_MIN: 60` (niżej niż w aplikacji) | demo bywa udostępniane szerzej, a każde zapytanie sięga do treści baz | | `ClusterIP` | wejście wyłącznie przez Ingress po https, jak prezentacja | ## ⚠️ Runbook zaczyna się od ostrzeżenia Bo to jedyna rzecz, którą trzeba pamiętać za każdym razem: demo pracuje na **produkcyjnej warstwie danych**. Kto dostaje adres, czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Pełna izolacja wymagałaby osobnej warstwy danych i nie jest dziś zrobiona. Zależność: PR aplikacji `feat/astroklient` — mergować **przed** albo razem (inaczej nie ma obrazu). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
gitea added 1 commit 2026-08-17 16:40:28 +00:00
feat(astroklient): wdrożenie wersji demonstracyjnej (PRE-28) 82c73f6aa5 
Deployment + Service (ClusterIP), wpięcie w kustomization, obraz dopisany do
image-updatera i runbook.

Obraz na liście image-updatera CELOWO od razu: obraz, którego tam nie ma, nigdy
się nie podbije, choćby CI go budowało — tak przez chwilę wisiał render na :latest.

Token międzywarstwowy i klucz łącza brane z TYCH SAMYCH sekretów co prezentacja:
demo nie jest furtką omijającą ochronę warstwy logicznej. Hasło demo natomiast
z OSOBNEGO sekretu astrololo-demo — demo odcina się jego skasowaniem, bez ruszania
kont głównej aplikacji.

Limit żądań niższy niż w pełnej aplikacji (60/min): demo bywa udostępniane szerzej,
a każde zapytanie sięga do treści baz.

Runbook zaczyna się od ostrzeżenia, bo to jedyna rzecz, którą trzeba pamiętać za
każdym razem: demo pracuje na PRODUKCYJNEJ warstwie danych, więc kto dostaje adres,
czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Pełna
izolacja wymagałaby osobnej warstwy danych i nie jest dziś zrobiona.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea added 1 commit 2026-08-17 16:59:21 +00:00
feat(astroklient): własna warstwa danych i pule per konto (PRE-29) e52284c88f 
Zmiana wobec pierwszej wersji: demo NIE pracuje już na produkcyjnej warstwie
danych. Ma własną logikę i własne dane, na osobnym udziale astrololo-demo,
pustym na starcie. Oryginalne bazy są dla demo nieosiągalne — nie przez
uprawnienia, tylko dlatego, że nie ma do nich drogi.

DLACZEGO OSOBNA JEST TEŻ WARSTWA LOGICZNA. Zna ona JEDEN adres warstwy danych,
więc astroklient korzystający z produkcyjnej logiki i tak trafiłby na produkcyjne
bazy. Izolacja musi sięgnąć obu warstw naraz, inaczej nie ma jej wcale. Jedyną
różnicą logic-demo wobec produkcyjnej jest DATA_URL — i to jest cała izolacja,
więc wpisanie tam „logic" cofnęłoby ją jednym słowem. Stąd komentarz przy tej
linii i sąsiedztwo obu plików.

PULE PER KONTO. Każde konto demo dostaje własny podkatalog na tym udziale,
niewidoczny dla pozostałych — w liście plików i w wynikach wyszukiwania. Konta
są listą `login:sekret` w sekrecie, bo jedno wspólne oznaczałoby wspólną pulę,
czyli klientów oglądających nawzajem swoje wgrania.

Ten sam OBRAZ co produkcja dla data i logic — różni je wyłącznie konfiguracja.
Osobny obraz to drugi kod do utrzymania i pewność, że kiedyś się rozjadą.

Logika demo nie dostaje kluczy do modeli językowych: astroklient nie umie o nie
prosić, więc nie ma powodu, żeby leżały w tym podzie.

Runbook opisuje IMPORT PULI KLIENTA do pełnej aplikacji — sedno całego układu,
bo klient przechodzący na pełną wersję nie może stracić wgrań. Jego pula to jeden
katalog: sprawdzenie kolizji nazw, kopiowanie z -n (nigdy nadpisania bazy
produkcyjnej), bez pliku stanu (produkcja ma własny), a na końcu świadome
włączenie w zakładce Pliki. Nie włączają się same, bo przeniesienie jest
czynnością techniczną, a decyzja o użyciu należy do właściciela.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea added 1 commit 2026-08-20 21:36:59 +00:00
refactor: astroklient → astroklient-demo a9ff6e1f68 
Nazwa `astroklient` zostaje zarezerwowana dla przyszłej wersji produkcyjnej;
obecna, demonstracyjna nazywa się od teraz `astroklient-demo`.

Zmiana obejmuje nazwy plików (astroklient-demo.yaml, astroklient-demo-stack.yaml,
README-astroklient-demo.md), Deployment i Service, etykiety selektorów, obraz
w rejestrze, alias w image-updaterze, wpisy w kustomization i odsyłacze w README.

`data-demo` i `logic-demo` zostają bez zmian — nie niosły starej nazwy.

Sprawdzone: `kubectl kustomize astrololo` składa komplet 27 zasobów, obraz to
astrololo-astroklient-demo, żadnego zdublowanego przyrostka ani gołego
`astroklient` nie zostało.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea changed title from astroklient — wdrożenie wersji demonstracyjnej (PRE-28) to astroklient-demo — wdrożenie wersji demonstracyjnej (PRE-28/29) 2026-08-20 21:37:05 +00:00
gitea added 1 commit 2026-08-20 22:21:54 +00:00
feat(astroklient-demo): własny klucz podpisu sesji (LOG-34) 7e0a51878e 
SESSION_SECRET w sekrecie astrololo-demo — WŁASNY, nie ten z pełnej aplikacji:
demo i produkcja nie mają powodu uznawać nawzajem swoich sesji.

W runbooku zapisana różnica wobec pełnej wersji: demo nie ma własnego wolumenu,
więc nie ma licznika sesji. Zdalne unieważnienie robi się przez DEMO_USERS —
usunięcie konta albo zmiana hasła natychmiast ubija jego otwarte sesje.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea closed this pull request 2026-08-26 14:39:35 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
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
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/deploy#19
Delete Branch "feat/astroklient"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?