Bidra

Gjør én liten endring på riktig sted og send den inn som en pull request.

Før du begynner

• Åpne en sak først, eller kommenter en som finnes. Si hva du vil endre og hvorfor.
• Vent på svar, så du ikke bygger noe som ikke blir slått sammen.
• Fullfør Oppsett så du kan bygge og kjøre HolyArrs.

Spørsmål går til Discord. Ideer går til r/HolyArrs. Saker (issues) er for feil og veikartet.

Send din første pull request

1. Finn modulen endringen hører hjemme i. Navnene i Moduler tilsvarer mappenavn, så et feil Discord-varsel er en endring i alerts.

2. Gjør endringen i app/backend/internal/<module>/ og app/frontend/src/lib/<module>/. Hold den til én rettelse eller én funksjon.

3. Bygg web-appen, så programmet, og prøv endringen i nettleseren. Se Oppsett.

4. Kjør sjekkene i Testing.

   Du skal ikke se noen feil.

5. Hvis du endret en side, kjør ende-til-ende-prosjektet for den, for eksempel npm --prefix app/frontend run e2e -- --project=movies.

6. Åpne pull requesten. Lenk til saken, si hva som er endret og hvordan du testet det, og legg til eller oppdater tester for endringen.

7. På din første pull request ber en bot deg signere lisensavtalen for bidragsytere. Svar med den ene setningen den ber om.

Merknad

Du beholder opphavsretten til arbeidet ditt. Avtalen lar HolyArrs tilbys under AGPL-3.0 og under en kommersiell lisens. Alt som slås sammen, forblir også tilgjengelig under AGPL-3.0. Teksten står i .github/CLA.md.

Valg

Hvor en endring hører hjemme

Endring	Gå til
En ny rute	Moduler
En ny modul	Moduler. Åpne en sak først
En tilbakeholdt funksjon	Oppsett
En versjon	Utgivelse av versjoner. Bare for vedlikeholdere

Hvordan en god pull request ser ut

• Skriv kommentarer som sier hvorfor koden gjør det den gjør. Ingen veikartnumre, datoer, navn eller tankestreker i kommentarer.
• La ordlyden i appen være i fred med mindre saken handler om ordlyd.
• La API-stier, feltnavn, innstillingsnøkler, tabellnavn og oppgavenavn som er utgitt, stå som de er. Legg til, aldri gi nytt navn.

Hvis det ikke fungerer

Symptom. En struktursjekk feiler. Årsak. Meldingen nevner filen og regelen. Løsning. Flytt koden, eller send rene data inn fra den høyere modulen. Se Moduler.

Symptom. Web-appen ser gammel ut. Årsak. Programmet serverer bygget det har innebygd. Løsning. Bygg web-appen på nytt før du bygger programmet.

Symptom. Ende-til-ende-testene kommer ikke i gang. Årsak. Testnettleseren er ikke installert. Løsning. Kjør npx --prefix app/frontend playwright install chromium.

For viderekomne

Regler en pull request må følge

• En modul snakker med en annen modul bare gjennom tjenesten dens (Go) eller index.ts (web). Aldri gjennom store-filene eller andre filer.
• SQL finnes bare i store*.go-filene til en modul, over modulens egne tabeller.
• En web-del legges i lib/ui bare når 2 eller flere moduler bruker den.
• Ingen util-, common-, shared- eller helpers-pakker.
• Alle kall til utsiden går gjennom core/outbound.

Tester sjekker disse reglene, så en feil import får bygget til å feile. Hele listen og navnene på sjekkene står i Moduler.

Hva CI kjører

Oppgave	Kjører
Web	check, lint, test, build og ende-til-ende-suiten
Go	go build, go vet og go test -timeout 60m ./... på amd64 og arm64, både native og under emulering
Race	go test -race ./...
Kontrakt	Samsvaret med openapi.json, scope-sjekker på hver rute, nedlastersuiten
Feil og skala	Kjøringer med krasj, treg skriving, dårlig tjeneste utenfra og minne
Image	Et utviklingsimage bygges, starter og melder versjonen sin

Detaljer om de lange kjøringene står i Testing.

Relatert

• Oppsett
• Testing
• Arkitektur