cf24c4d47346773fa29e8cf02d8fc5e8a47e2c8e
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
cf24c4d473 |
ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m22s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m30s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m25s
Testy / Testy astrodemo (pull_request) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 7s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 4s
build-render / build (push) Successful in 2m39s
build / build (push) Successful in 10s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m20s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m25s
Testy / Testy astrodemo (push) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 7s
Testy / Kontrola składni wszystkich warstw (push) Successful in 4s
Rejestr obrazów rósł, bo `build.yaml` budował CZTERY obrazy przy każdym pushu do mastera, niezależnie od tego, co się zmieniło. Zmiana w samej prezentacji dawała nowe wersje data, logic i astrodemo — identyczne co do zawartości, różniące się wyłącznie tagiem. Render i silnik B miały filtry ścieżek od początku (build-render.yaml, build-swisseph.yaml) i budują się tylko przy własnych zmianach. Ta zmiana przenosi tę samą zasadę do głównego pipeline'u, licząc różnicę wobec poprzedniego commita. Kontekstem budowania każdego obrazu jest wyłącznie `./services/<nazwa>`, więc porównanie ścieżek jest dokładne, a nie przybliżone. Sprawdzone na ośmiu ostatnich commitach mastera: dwa refaktory prezentacji dają sam `presentation`, poprawka Dockerfile'a astrodemo daje samo `astrodemo`, a commit ruszający link_crypto w pięciu usługach — komplet. Bez porównania (pierwszy commit, przepisana historia) budujemy wszystko: lepiej zbudować za dużo niż wypuścić obraz ze starym kodem pod nowym tagiem. SKUTEK UBOCZNY DO ŚWIADOMOŚCI: tagi w kustomization mogą się teraz rozjechać między usługami, bo nie każda dostaje nową wersję z każdego commita. Tak ma być — image-updater śledzi każdy obraz osobno i przypina to, co istnieje. ZABEZPIECZENIE PRZED CICHYM POMINIĘCIEM. Usługa, której nie ma na żadnej liście, nigdy się nie zbuduje i nikt tego nie zauważy: brak obrazu wygląda potem na problem z rejestrem albo z siecią. Ten sam mechanizm kosztował nas już raz, przy liście obserwowanych obrazów w image-updaterze. Pętla po `services/*/` zatrzymuje budowanie i mówi wprost, co dopisać. Sprawdzone także od strony negatywnej — podstawiony katalog nowej usługi kończy przebieg kodem 1. SPRZĄTANIE NA RUNNERZE, w build.yaml i w build-render.yaml, z `if: always()` — bo to po NIEUDANYM budowaniu zostaje najwięcej śmieci, a kolejny przebieg zaczyna od mniejszego zapasu miejsca niż poprzedni. Tak zatkał się dysk przy renderze z TeX Live. Filtr `until=168h` zostawia tydzień, więc warstwy bazowe i cache przeżywają i build nie zaczyna od zera. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
2e9d3706ec |
astrodemo: zmiana nazwy, rebase na mastera i domknięcie wycieków
Testy / Testy warstwy logicznej (silnik) (push) Failing after 4m50s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m25s
Testy / Testy astrodemo (push) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 8s
Testy / Kontrola składni wszystkich warstw (push) Successful in 5s
Testy / Testy warstwy logicznej (silnik) (pull_request) Failing after 4m43s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m25s
Testy / Testy astrodemo (pull_request) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 6s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 4s
Pierwszy z pięciu kroków budowy trzech produktów: astrodemo (dwie funkcje) → astroklient (pełne astro bez AI) → astrololo (wszystko). Nazwa „astroklient" zostaje zwolniona dla warstwy pośredniej, więc dotychczasowe astroklient-demo nazywa się teraz astrodemo. REBASE. Cztery commity demo przeniesione na aktualnego mastera. Konflikt był jeden — rejestr wymagań (xlsx, binarny, git go nie scali). Master dodał LOG-34, gałąź demo PRE-28 i PRE-29; żaden wspólny wiersz się nie różnił, więc scalone ręcznie: 148 pozycji, wszystkie trzy obecne. ZMIANA NAZWY. Katalog, ciasteczko sesji (astrodemo_sesja), zmienne ASTRODEMO_USERS/USER/PASSWORD, CI, README, docstringi. Ponieważ PR z demo nigdy nie został zmergowany, usługa nie jest nigdzie wdrożona — zmiana nazw niczego nie migruje i nikogo nie wylogowuje. WYCIEKI. astrodemo powstało przed audytem z PRE-27, więc miało komplet tych samych dziur: - /static omijało bramkę (PUBLIC_PREFIXES), a pierwszy komentarz w styles.css brzmiał „Nie kopiujemy stylów pełnej aplikacji" — czyli anonimowy curl dowiadywał się, że istnieje pełna aplikacja. Zasoby idą teraz trasą z jawną listą, komentarze są zdejmowane przy serwowaniu. - Komunikat awarii wypisywał na ekran treść wyjątku httpx, z nazwą usługi i portem. Teraz jedno neutralne zdanie, szczegóły do dziennika. - /health oddawał nazwę warstwy. Teraz samo „ok". - Dziesięć komentarzy i docstringów tłumaczyło decyzje przez porównanie z „pełną aplikacją". Obraz tej usługi się KOMUŚ ODDAJE, więc kto go dostanie, przeczyta też komentarze. Przepisane tak, żeby opisywały tę usługę samą w sobie. - Nagłówek main.py twierdził, że demo dzieli pulę plików z produkcją. To nieprawda od PRE-29 (pule per konto) — opis poprawiony. ZAPORA SŁOWNIKOWA, dwupoziomowa. Poziom „wszędzie" (także w kodzie serwera, bo obraz się oddaje) obejmuje wzmianki o większym rodzeństwie, o modelu językowym i o funkcjach, których tu nie ma. Poziom „do przeglądarki" dokłada słownictwo mechanizmów. Test sprawdza odpowiedzi ORAZ drzewo plików. Jeden wyjątek jest jawny i opisany: stałe protokołu łącza (X-Astrololo-Token, X-Astrololo-Enc, typ treści, etykieta HKDF) niosą nazwę rodziny produktów. Są wspólne z warstwą logiczną, więc zmiana wymaga jednoczesnej podmiany we wszystkich usługach i rotacji — osobna decyzja. Osobny test pilnuje warunku, pod jakim to zostaje: że nie docierają do przeglądarki. Wcześniej przechodziły tylko dlatego, że regex nie dopasowywał po myślniku — przypadek, nie decyzja. Przy okazji: komunikat „ramka bez znacznika astrololo" zmieniony na neutralny we WSZYSTKICH PIĘCIU kopiach link_crypto.py (presentation, astrodemo, logic, data, render), żeby nie rozjechały się przed scaleniem w rdzeń. Te kopie to 2625 linii tego samego kodu. Testy: astrodemo 27, presentation 358, logic 342, data 42, render 41. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
16cf25468f |
refactor: astroklient → astroklient-demo
Nazwa `astroklient` zostaje zarezerwowana dla przyszłej wersji produkcyjnej programu; obecna, demonstracyjna nazywa się od teraz `astroklient-demo`. Zmiana obejmuje katalog usługi, nazwę pliku testów, obraz w rejestrze (astrololo-astroklient-demo), job w CI, pętlę budowania obrazów, tytuł i nagłówek strony, nazwy loggerów, realm logowania, pole `layer` w /health oraz wymagania PRE-28/29 w xlsx. DWIE PUŁAPKI PODMIANY, obie sprawdzone po fakcie: Zdublowany przyrostek. `astroklient-demo` zawiera `astroklient`, więc powtórna podmiana dałaby `astroklient-demo-demo`. Sprawdziłem najpierw, że nigdzie nie ma jeszcze nowej nazwy, i dopiero wtedy podmieniłem raz. Polska odmiana. Ślepa podmiana zamieniła „astroklienta" na „astroklient-demoa” w czterech miejscach; poprawione na „astroklienta-demo". Tytuł FastAPI wyszedłby jako „astroklient-demo · demo", a nazwa jobu jako „Testy astroklienta-demo (wersja demo)" — oba skrócone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
e7b6d5013b |
feat(astroklient): wersja demonstracyjna o dwóch funkcjach (PRE-28)
Osobna warstwa prezentacji: dodanie pliku bazy i zapytanie o interpretację urodzeniową. Nic więcej. OSOBNA USŁUGA, NIE KONTO Z OGRANICZENIAMI. Mechanizm uprawnień z PRE-27 umiałby to ukryć w pełnej aplikacji, ale ukrycie a nieobecność to dwie różne rzeczy: tutaj pozostałych funkcji NIE MA W OBRAZIE — nie ma tras, nie ma szablonów, nie ma nawet metod w kliencie warstwy logicznej. Demo można komuś oddać, nie oddając przy okazji kodu reszty programu. Test porównuje zbiór tras aplikacji i zbiór metod klienta z listą dokładną, więc dopisanie czegokolwiek zapala się od razu. WGRANIE I WŁĄCZENIE TO JEDNA CZYNNOŚĆ. W pełnej aplikacji to dwie osobne decyzje (DAN-27), bo tam ktoś nad tym panuje. Tutaj „dodać plik do bazy" musi znaczyć, że plik od razu bierze udział w wyszukiwaniu — inaczej po wgraniu nic by się nie zmieniło i demo wyglądałoby na zepsute. Walidacja zostaje: plik o złym układzie nie wchodzi do użytku, ale też NIE JEST tracony, a komunikat nie zdradza reguł, bo te zna wyłącznie administrator. Osobny test szuka w komunikacie śladów mechanizmu. KONTO OSOBNE (DEMO_USER/DEMO_PASSWORD), nie współdzielone z główną aplikacją. Demo pracuje na TEJ SAMEJ warstwie danych co produkcja — świadoma decyzja właściciela — więc kto ma do niego dostęp, czyta oryginalne bazy, a jego wgrania trafiają do produkcyjnego zbioru. Własne poświadczenia pozwalają odciąć demo jedną zmienną, bez ruszania kont głównej aplikacji i bez zmiany hasła komukolwiek. Zapisane wprost w README usługi i w manifeście, nie tylko w tej wiadomości. Rozmowa z warstwą logiczną idzie tym samym szyfrowanym łączem (PRE-16) i pod tym samym tokenem międzywarstwowym (LOG-32) — demo nie jest furtką omijającą ochronę. Automatyczna dokumentacja wyłączona, jak w pełnej aplikacji: /docs wypisałoby komplet tras, a demo ma nie zdradzać nawet własnej powierzchni. Zależności celowo krótsze niż w prezentacji: bez Excela, bez stref czasowych z lokalizacji, bez niczego pod kosmogram. Każda zbędna zależność w obrazie demo to kolejna rzecz do pilnowania. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
9323803cb4 |
tt
build / build (push) Successful in 5m31s
|
||
|
|
73f39e7df8 | build |