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>
mmacierzanka
lgooseandClaude Bot