Bidrag

Lav én lille ændring det rigtige sted og send den som en pull request.

Før du begynder

• Åbn først en issue, eller kommenter på en eksisterende. Skriv, hvad du vil ændre, og hvorfor.
• Vent på svar, så du ikke bygger noget, der ikke bliver flettet ind.
• Gennemfør Opsætning, så du kan bygge og køre HolyArrs.

Spørgsmål hører hjemme på Discord. Idéer hører hjemme på r/HolyArrs. Issues er til fejl og køreplanen.

Send din første pull request

1. Find det modul, din ændring hører til i. Navnene i Moduler svarer til mappenavne, så en forkert Discord-besked er en ændring i alerts.

2. Lav ændringen i app/backend/internal/<module>/ og app/frontend/src/lib/<module>/. Hold den til én rettelse eller én funktion.

3. Byg web-appen og derefter programmet, og prøv ændringen i browseren. Se Opsætning.

4. Kør tjekkene i Testning.

   Du bør ikke se nogen fejl.

5. Hvis du har ændret en side, så kør dens end-to-end-projekt, for eksempel npm --prefix app/frontend run e2e -- --project=movies.

6. Åbn pull requesten. Link til issuen, skriv hvad der er ændret, og hvordan du testede det, og tilføj eller opdater tests til ændringen.

7. På din første pull request beder en bot dig om at underskrive bidragsyderaftalen. Svar med den ene sætning, den beder om.

Note

Du beholder ophavsretten til dit arbejde. Aftalen gør, at HolyArrs kan tilbydes under AGPL-3.0 og under en kommerciel licens. Alt, der bliver flettet ind, er også stadig tilgængeligt under AGPL-3.0. Teksten ligger i .github/CLA.md.

Valg

Hvor en ændring hører til

Ændring	Gå til
En ny rute	Moduler
Et nyt modul	Moduler. Åbn først en issue
En tilbageholdt funktion	Opsætning
En version	Udgivelse. Kun for vedligeholdere

Sådan ser en god pull request ud

• Skriv kommentarer, der siger, hvorfor koden gør det, den gør. Ingen køreplansnumre, datoer, navne eller tankestreger i kommentarer.
• Lad appens ordlyd være i fred, medmindre issuen handler om ordlyd.
• Behold udgivne API-stier, feltnavne, indstillingsnøgler, tabelnavne og opgavenavne, som de er. Tilføj, omdøb aldrig.

Hvis det ikke virker

Symptom. Et strukturtjek fejler. Årsag. Beskeden nævner filen og reglen. Løsning. Flyt koden, eller send almindelige data ind fra det højere modul. Se Moduler.

Symptom. Web-appen ser gammel ud. Årsag. Programmet serverer det build, det har indlejret. Løsning. Byg web-appen igen, før du bygger programmet.

Symptom. End-to-end-tests kan ikke starte. Årsag. Testbrowseren er ikke installeret. Løsning. Kør npx --prefix app/frontend playwright install chromium.

For erfarne

Regler, en pull request skal overholde

• Et modul taler kun med et andet modul gennem dets service (Go) eller dets index.ts (web). Aldrig gennem dets store eller dets filer.
• SQL findes kun i et moduls store*.go-filer, over modulets egne tabeller.
• En webdel kommer kun i lib/ui, når 2 eller flere moduler bruger den.
• Ingen util-, common-, shared- eller helpers-pakker.
• Alle kald udad går gennem core/outbound.

Tests tjekker disse regler, så en forkert import får buildet til at fejle. Den fulde liste og navnene på tjekkene står i Moduler.

Hvad CI kører

Opgave	Kører
Web	check, lint, test, build og end-to-end-pakken
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	Match med openapi.json, scope-tjek på hver rute, downloader-pakken
Fejl og skala	Kørsler med nedbrud, langsom skrivning, dårlig ekstern tjeneste og hukommelse
Image	Et udviklingsimage bygger, starter og melder sin version

Detaljer om de lange kørsler står i Testning.

Se også

• Opsætning
• Testning
• Arkitektur