Krok padał na runnerze bez żadnego komunikatu. Powód był podwójny:
- asercja zakładała, że bez backendu nginx odpowie 502, a to zależy od
tego, jak szybko zawiedzie DNS. Na runnerze zapytanie wisiało 30 sekund,
aż do domyślnego resolver_timeout.
- grep bez dopasowania kończy się kodem 1, a Gitea uruchamia kroki w
bash -e -o pipefail, więc podstawienie zmiennej przerywało cały krok,
zanim zdążył wypisać powód. Lokalnie tego nie było widać, bo zsh nie
ustawia tych flag.
Zamiast opierać się na tym, że proxy zawiedzie, job stawia teraz atrapę
backendu pod nazwą discord-bot - dokładnie tą, którą wskazuje nginx.conf
i compose.yaml - i sprawdza, że przez proxy wraca treść z atrapy. Test
przechodzi więc wtedy, gdy przekazywanie faktycznie działa, a nie wtedy,
gdy zawodzi w oczekiwany sposób. Sprawdzane jest też /ws.
Pozostałe usztywnienia: limit czasu na każde zapytanie, || true tam, gdzie
brak dopasowania jest poprawnym wynikiem, jawne komunikaty błędów z logiem
kontenera oraz sprzątanie kontenerów i sieci przez trap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Workflow .gitea/workflows/frontend.yaml z dwoma jobami:
- verify npm ci, ESLint, kontrola typów, build produkcyjny i test dymny
- image walidacja compose.yaml, build obrazu panelu i sprawdzenie
działającego kontenera; job czeka na verify
Test dymny działa na zbudowanym artefakcie, a nie na źródłach, więc
sprawdza dokładnie to, co trafia do obrazu.
Job image weryfikuje trzy rzeczy w uruchomionym kontenerze: czy nginx
oddaje panel, czy nieznana ścieżka wraca jako index.html (fallback SPA)
oraz czy /api jest przekazywane do backendu. Backendu w tym kroku nie ma,
więc oczekiwaną odpowiedzią jest błąd bramy - 502 dowodzi, że reguła proxy
istnieje i celuje w usługę discord-bot, podczas gdy 404 oznaczałoby, że
nginx potraktował /api jak ścieżkę aplikacji.
Filtry paths ograniczają uruchomienia do zmian w katalogu frontend,
compose.yaml i samym workflow.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Workflow .gitea/workflows/backend.yaml z trzema jobami:
- lint ruff check oraz ruff format --check --diff
- test testy jednostkowe i kontrakt API, plus compileall całego pakietu
- image testowy build obrazu; job czeka na lint i test
Job image nie poprzestaje na zbudowaniu obrazu - uruchamia kontener bez
prawdziwego tokenu Discorda i czeka, aż /api/status odpowie. Panel łączy
się z backendem po sieci, więc sam start procesu niczego nie dowodzi.
Zapytanie leci z wnętrza kontenera, dzięki czemu krok nie zależy od tego,
czy runner ma zainstalowanego curla albo wgeta.
Filtry paths ograniczają uruchomienia do zmian w kodzie Pythona,
zależnościach, konfiguracji lintera, Dockerfile i samym workflow.
Zależności instalują się z gotowych kółek, więc obraz CI nie potrzebuje
kompilatora. ffmpeg i libopus są wymagane dopiero przy odtwarzaniu,
a testy nie dotykają warstwy audio.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mmacierzanka
lgooseandClaude Bot