Współtworzenie

Konfiguracja

Zrób jedną małą zmianę we właściwym miejscu i wyślij ją jako pull request.

Zanim zaczniesz

Najpierw otwórz zgłoszenie (issue) albo skomentuj istniejące. Napisz, co chcesz zmienić i dlaczego.
Poczekaj na odpowiedź, żeby nie budować czegoś, co nie zostanie przyjęte.
Przejdź Konfigurację środowiska, żeby móc zbudować i uruchomić HolyArrs.

Pytania zadawaj na Discordzie. Pomysły zgłaszaj na r/HolyArrs. Issues służą do błędów i planów rozwoju.

Wyślij pierwszy pull request

Znajdź moduł, do którego należy twoja zmiana. Nazwy ze strony Moduły odpowiadają nazwom folderów, więc zły alert na Discordzie to zmiana w alerts.
Zrób zmianę w app/backend/internal/<module>/ i app/frontend/src/lib/<module>/. Ogranicz się do jednej poprawki albo jednej funkcji.
Zbuduj aplikację webową, potem program, i wypróbuj zmianę w przeglądarce. Zobacz Konfigurację środowiska.
Uruchom kontrole ze strony Testy.

Nie powinno być żadnego błędu.
Jeśli zmieniasz stronę, uruchom jej projekt end-to-end, na przykład npm --prefix app/frontend run e2e -- --project=movies.
Otwórz pull request. Podlinkuj zgłoszenie, opisz zmianę i sposób testowania oraz dodaj lub zaktualizuj testy do zmiany.
Przy pierwszym pull requeście bot poprosi o podpisanie umowy licencyjnej współtwórcy (CLA). Odpowiedz jednym zdaniem, o które prosi.

Opcje

Gdzie trafia zmiana

Zmiana	Przejdź do
Nowa trasa	Moduły
Nowy moduł	Moduły. Najpierw otwórz zgłoszenie
Funkcja wstrzymana	Konfiguracja środowiska
Wersja	Wydawanie wersji. Tylko dla opiekunów

Jak wygląda dobry pull request

Pisz komentarze, które mówią, dlaczego kod robi to, co robi. Bez numerów z planu rozwoju, dat, imion i długich myślników w komentarzach.
Nie ruszaj tekstów w aplikacji, chyba że zgłoszenie dotyczy tekstów.
Wydane ścieżki API, nazwy pól, klucze ustawień, nazwy tabel i nazwy zadań zostaw bez zmian. Dodawaj, nigdy nie zmieniaj nazw.

Jeśli to nie działa

Objaw. Kontrola struktury kończy się błędem. Przyczyna. Komunikat podaje plik i regułę. Rozwiązanie. Przenieś kod albo przekaż zwykłe dane z wyższego modułu. Zobacz Moduły.

Objaw. Aplikacja webowa wygląda staro. Przyczyna. Program serwuje build, który ma wbudowany. Rozwiązanie. Zbuduj aplikację webową ponownie, przed programem.

Objaw. Testy end-to-end nie startują. Przyczyna. Przeglądarka testowa nie jest zainstalowana. Rozwiązanie. Wykonaj npx --prefix app/frontend playwright install chromium.

Dla zaawansowanych

Reguły, których pull request musi przestrzegać

Moduł rozmawia z innym modułem tylko przez jego serwis (Go) lub jego index.ts (web). Nigdy przez jego store ani pliki.
SQL leży tylko w plikach store*.go modułu, nad jego własnymi tabelami.
Część webowa trafia do lib/ui tylko wtedy, gdy używają jej 2 lub więcej modułów.
Żadnych pakietów util, common, shared ani helpers.
Każde wywołanie na zewnątrz idzie przez core/outbound.

Testy sprawdzają te reguły, więc zły import przerwie build. Pełna lista i nazwy kontroli są na stronie Moduły.

Co uruchamia CI

Zadanie	Uruchamia
Web	`check`, `lint`, `test`, `build` i pełny zestaw end-to-end
Go	`go build`, `go vet` i `go test -timeout 60m ./...` na `amd64` i `arm64`, natywnie i w emulacji
Race	`go test -race ./...`
Kontrakt	Zgodność z `openapi.json`, kontrole zakresów na każdej trasie, zestaw testów downloaderów
Awarie i skala	Uruchomienia z awarią, wolnym zapisem, zepsutą usługą zewnętrzną i zużyciem pamięci
Image	Image deweloperski buduje się, startuje i podaje swoją wersję

Szczegóły długich uruchomień są na stronie Testy.

Powiązane strony

HolyArrs jest darmowy. Jeśli oszczędził ci czas, daj mu gwiazdkę na GitHubie, zostań sponsorem albo postaw mi kawę.