Bidra

Gör en liten ändring på rätt ställe och skicka den som en pull request.

Innan du börjar

• Öppna först ett ärende, eller kommentera ett som redan finns. Skriv vad du vill ändra och varför.
• Vänta på svar, så att du inte bygger något som inte kommer att tas in.
• Slutför Konfiguration så att du kan bygga och köra HolyArrs.

Frågor går till Discord. Idéer går till r/HolyArrs. Ärenden är till för buggar och färdplanen.

Skicka din första pull request

1. Hitta modulen din ändring hör hemma i. Namnen i Moduler motsvarar mappnamn, så en felaktig Discord-avisering är en ändring i alerts.

2. Gör ändringen i app/backend/internal/<module>/ och app/frontend/src/lib/<module>/. Håll dig till en enda rättning eller en enda funktion.

3. Bygg webbappen och sedan programmet, och prova ändringen i webbläsaren. Se Konfiguration.

4. Kör kontrollerna i Testning.

   Du ska inte se något fel.

5. Om du ändrade en sida kör du dess end-to-end-projekt, till exempel npm --prefix app/frontend run e2e -- --project=movies.

6. Öppna pull requesten. Länka ärendet, skriv vad som ändrats och hur du testade, och lägg till eller uppdatera tester för ändringen.

7. På din första pull request ber en bot dig skriva under avtalet för bidragsgivare. Svara med den enda mening den ber om.

Note

Du behåller upphovsrätten till ditt arbete. Avtalet gör att HolyArrs kan erbjudas under AGPL-3.0 och under en kommersiell licens. Allt som tas in finns också kvar under AGPL-3.0. Texten finns i .github/CLA.md.

Val

Vart en ändring hör hemma

Ändring	Gå till
En ny route	Moduler
En ny modul	Moduler. Öppna ett ärende först
En tillbakahållen funktion	Konfiguration
En version	Utgivning. Bara för underhållare

Så ser en bra pull request ut

• Skriv kommentarer som förklarar varför koden gör som den gör. Inga färdplansnummer, datum, namn eller långa tankstreck i kommentarer.
• Låt appens ordval vara, om inte ärendet handlar om ordval.
• Behåll släppta API-sökvägar, fältnamn, nyckelnamn för inställningar, tabellnamn och jobbnamn som de är. Lägg till, byt aldrig namn.

Om det inte fungerar

Symptom. En strukturkontroll misslyckas. Orsak. Meddelandet nämner filen och regeln. Lösning. Flytta koden, eller skicka ner vanlig data från den högre modulen. Se Moduler.

Symptom. Webbappen ser gammal ut. Orsak. Programmet serverar den build det har inbyggd. Lösning. Bygg webbappen igen före programmet.

Symptom. End-to-end-testerna kan inte starta. Orsak. Testwebbläsaren är inte installerad. Lösning. Kör npx --prefix app/frontend playwright install chromium.

För experter

Regler en pull request måste följa

• En modul pratar med en annan modul bara via dess tjänst (Go) eller dess index.ts (webb). Aldrig via dess store eller dess filer.
• SQL finns bara i en moduls store*.go-filer, över modulens egna tabeller.
• En webbdel hamnar i lib/ui bara när 2 eller fler moduler använder den.
• Inga paket som heter util, common, shared eller helpers.
• Varje anrop utåt går genom core/outbound.

Tester kontrollerar reglerna, så en felaktig import får bygget att misslyckas. Hela listan och kontrollernas namn finns i Moduler.

Vad CI kör

Jobb	Kör
Web	check, lint, test, build och end-to-end-sviten
Go	go build, go vet och go test -timeout 60m ./... på amd64 och arm64, både nativt och under emulering
Race	go test -race ./...
Contract	Matchningen mot openapi.json, behörighetskontroller på varje route, nedladdarsviten
Fault and scale	Körningar med krasch, långsam skrivning, felande externa tjänster och minne
Image	En utvecklingsimage byggs, startar och rapporterar sin version

Detaljer om de långa körningarna finns i Testning.

Relaterat

• Konfiguration
• Testning
• Arkitektur