10970c579f
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m19s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m26s
Testy / Testy astrodemo (pull_request) Failing after 0s
Testy / Testy astroklient (pull_request) Successful in 9m29s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 7s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 5s
build / build (push) Successful in 19s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m25s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m26s
Testy / Testy astrodemo (push) Failing after 0s
Testy / Testy astroklient (push) Successful in 9m29s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 7s
Testy / Kontrola składni wszystkich warstw (push) Successful in 5s
Trzeci produkt drabiny: astrodemo (dwie funkcje) → astroklient → astrololo. Po trzech poprzednich krokach jest cienki, bo jest ZŁOŻENIEM, a nie kopią: własne main.py z ośmioma importami, a rdzeń — ekrany, szablony, zasoby — bierze z warstwy prezentacji przy budowaniu obrazu. Jedno źródło, dwa produkty; inaczej te same 2500 linii szablonów żyłyby w dwóch egzemplarzach i rozjechały się w ciągu tygodni, po cichu. CO MA: Horoskop, Interpretacje, Kalendarz, Synastria, Sygnifikatory, wgrywanie plików. Wyszukiwarka miejsca i strefa czasowa zgodnie z ustaleniem. CZEGO NIE MA I DLACZEGO NIE DA SIĘ WŁĄCZYĆ: plików usuniętych wg usun.txt nie ma w obrazie. Nie istnieje uprawnienie, którym dałoby się je odsłonić, bo katalog funkcji składa się ze ZGŁOSZEŃ ekranów obecnych w obrazie. To dlatego „każde konto dostaje wszystko, co ta usługa umie" jest tu bezpieczne i nie wymaga wypisywania listy: zbiór liczy się z katalogu, więc opisuje ten produkt. KONTA jak w astrodemo: z konfiguracji środowiska (ASTROKLIENT_USERS), jeden poziom dostępu, bez pliku kont i bez ekranu ich zakładania. Konta rozdziela się po to, żeby każde miało własną pulę plików. PULE PER KONTO — tu była realna dziura. Warstwa logiczna przenosiła pulę tylko przy raporcie i operacjach na plikach, więc Kalendarz i Sygnifikatory czytałyby CAŁY udział: jedno konto widziałoby pliki drugiego, mimo obietnicy izolacji. Domknięte: TimelineRequest i QueryRequest niosą teraz pulę, a QueryService buduje klienta danych na żądanie. Pula jedzie w każdym żądaniu w dół i bierze się z kontekstu ustawianego przy wejściu, nigdy z formularza. Test podstawia `tenant=ktos-inny` w POST i sprawdza, że w dół poszedł login zalogowanego. WARSTWA WSPÓLNA ROZDZIELONA OD POJĘCIA ADMINISTRATORA. base.html miał wpisany na sztywno warunek `can(request, 'admin')` i odsyłacz do ekranu kont — czyli w produkcie bez tego ekranu zostawał martwy link i nazwa czegoś, czego nie ma. Rejestr niesie teraz wymagane uprawnienie, a szablon dostaje gotową listę. Podstawa przestała też importować moduły służące jednemu ekranowi (konta, stany plików), bo produkt bez tego ekranu wlókł ich zależności. ZAPORA SŁOWNIKOWA NAD REALNYM DRZEWEM. Test buduje złożenie tak samo jak Dockerfile i szuka słów o funkcjach, których nie ma — w odpowiedziach ORAZ w plikach. Pierwsza wersja znalazła dziesięć trafień, w tym trzy moje własne docstringi WYLICZAJĄCE nieobecne funkcje: zdanie „nie ma tu generowania tekstu" mówi wprost, że coś takiego istnieje, więc jest takim samym śladem jak przycisk. Po poprawkach: zero. Test ma kontrolę negatywną — podrzucony plik ma go wywrócić. usun.txt jest DANYMI, nie tekstem w Dockerfile: czyta go też test pilnujący, żeby zgadzał się ze złożeniem w main.py. Rozjazd znaczyłby albo martwy kod w obrazie, albo błąd dopiero przy uruchomieniu. CI: astroklient buduje się z KORZENIA repozytorium (jego Dockerfile sięga po rdzeń), a zmiana w warstwie prezentacji też go przebudowuje — bez tego jego obraz zostawałby ze starymi ekranami, a różnicy nie byłoby widać do zgłoszenia użytkownika. Testy: astroklient 12, presentation 368, astrodemo 28, logic 342, data 42, render 41. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
113 lines
5.1 KiB
YAML
113 lines
5.1 KiB
YAML
name: build
|
|
|
|
# Buduje obrazy usług, które dzielą warstwę logiczną i łącze: data, logic,
|
|
# presentation, astrodemo. Render i silnik B mają własne pipeline'y, bo są ciężkie
|
|
# i rzadko się zmieniają (build-render.yaml, build-swisseph.yaml).
|
|
on:
|
|
push:
|
|
branches: [master]
|
|
|
|
jobs:
|
|
build:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
with:
|
|
# Dwa commity, bo porównujemy z poprzednim. Domyślny płytki klon ma
|
|
# jeden i `HEAD^` w nim nie istnieje.
|
|
fetch-depth: 2
|
|
|
|
- name: Login
|
|
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login gitea.czernobog.pl -u gitea --password-stdin
|
|
|
|
- name: Build & push (tylko usługi, które się zmieniły)
|
|
run: |
|
|
set -eu
|
|
TAG=${GITHUB_SHA::8}
|
|
USLUGI="data logic presentation astrodemo astroklient"
|
|
# Usługi z własnym pipeline'em — celowo poza tą pętlą.
|
|
OSOBNE="render engine-swisseph"
|
|
|
|
# Usługa, której nie ma na żadnej z list, nigdy się nie zbuduje i NIKT
|
|
# tego nie zauważy: brak obrazu wygląda potem na problem z rejestrem.
|
|
# Ten sam mechanizm już nas kosztował przy liście obserwowanych obrazów
|
|
# w image-updaterze. Lepiej zatrzymać budowanie i powiedzieć wprost.
|
|
for KATALOG in services/*/; do
|
|
NAZWA=$(basename "$KATALOG")
|
|
case " $USLUGI $OSOBNE " in
|
|
*" $NAZWA "*) ;;
|
|
*) echo "BŁĄD: usługa '$NAZWA' nie jest na żadnej liście budowania."
|
|
echo "Dopisz ją do USLUGI w tym pliku albo daj jej własny workflow"
|
|
echo "(jak render i engine-swisseph), zależnie od tego, czy ma"
|
|
echo "powstawać z każdego commita produktu."
|
|
exit 1 ;;
|
|
esac
|
|
done
|
|
|
|
# Kontekstem budowania każdego obrazu jest WYŁĄCZNIE ./services/<nazwa>,
|
|
# więc zmiana poza tym katalogiem nie może wpłynąć na jego zawartość.
|
|
# Dzięki temu porównanie ścieżek jest dokładne, a nie przybliżone.
|
|
if POPRZEDNI=$(git rev-parse --verify HEAD^ 2>/dev/null); then
|
|
ZMIENIONE=$(git diff --name-only "$POPRZEDNI" HEAD)
|
|
else
|
|
# Pierwszy commit albo przepisana historia — nie ma z czym porównać,
|
|
# więc budujemy wszystko. Lepiej zbudować za dużo niż wypuścić obraz
|
|
# ze starym kodem pod nowym tagiem.
|
|
echo "Brak poprzedniego commita — buduję komplet."
|
|
ZMIENIONE=""
|
|
fi
|
|
|
|
# Zmiana w samym pliku workflow dotyczy wszystkich obrazów naraz.
|
|
if [ -z "$ZMIENIONE" ] || echo "$ZMIENIONE" | grep -q '^\.gitea/workflows/build\.yaml$'; then
|
|
DO_BUDOWY="$USLUGI"
|
|
else
|
|
DO_BUDOWY=""
|
|
for SVC in $USLUGI; do
|
|
if echo "$ZMIENIONE" | grep -q "^services/$SVC/"; then
|
|
DO_BUDOWY="$DO_BUDOWY $SVC"
|
|
fi
|
|
done
|
|
# astroklient bierze rdzeń z warstwy prezentacji, więc zmiana TAMTEJ
|
|
# też go dotyczy. Bez tego jego obraz zostawałby ze starymi ekranami,
|
|
# a różnicy nie byłoby widać aż do zgłoszenia użytkownika.
|
|
if echo "$ZMIENIONE" | grep -q "^services/presentation/" \
|
|
&& ! echo "$DO_BUDOWY" | grep -q "astroklient"; then
|
|
DO_BUDOWY="$DO_BUDOWY astroklient"
|
|
fi
|
|
fi
|
|
|
|
if [ -z "$(echo "$DO_BUDOWY" | tr -d ' ')" ]; then
|
|
echo "Żadna z usług się nie zmieniła — nie ma czego budować."
|
|
echo "Wdrożone tagi zostają na poprzednich wersjach, i tak ma być."
|
|
exit 0
|
|
fi
|
|
|
|
echo "Buduję:$DO_BUDOWY (tag $TAG)"
|
|
for SVC in $DO_BUDOWY; do
|
|
# astroklient buduje się z KORZENIA repozytorium, bo jego Dockerfile
|
|
# sięga po rdzeń do services/presentation. Pozostałe mają kontekst
|
|
# ograniczony do własnego katalogu — i tak ma zostać, bo to właśnie
|
|
# ten kontekst gwarantuje, że nie wciągną niczego spoza siebie.
|
|
if [ "$SVC" = "astroklient" ]; then
|
|
docker build -f services/astroklient/Dockerfile \
|
|
-t gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG .
|
|
else
|
|
docker build -t gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG ./services/$SVC
|
|
fi
|
|
docker push gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG
|
|
done
|
|
echo "Tag: $TAG"
|
|
|
|
# Sprzątanie ZAWSZE, także po nieudanym budowaniu — to właśnie po awarii
|
|
# zostaje najwięcej śmieci, a kolejny przebieg zaczyna od mniejszego zapasu
|
|
# miejsca niż poprzedni. Tak zatkał się dysk przy budowaniu rendera.
|
|
- name: Sprzątanie po budowaniu
|
|
if: always()
|
|
run: |
|
|
docker system df || true
|
|
# `until=168h` zostawia tydzień: warstwy bazowe i cache z ostatnich dni
|
|
# przeżywają, więc kolejny build nie zaczyna od zera, a stare znikają.
|
|
docker system prune -af --filter "until=168h" || true
|
|
docker builder prune -f --filter "until=168h" || true
|
|
docker system df || true
|