Bijdragen

Maak één kleine wijziging op de juiste plek en stuur die in als pull request.

Voor je begint

• Open eerst een issue, of reageer op een bestaande. Schrijf wat je wilt wijzigen en waarom.
• Wacht op een antwoord, zodat je niets bouwt dat niet wordt samengevoegd.
• Rond de Configuratie af, zodat je HolyArrs kunt bouwen en draaien.

Vragen gaan naar Discord. Ideeën gaan naar r/HolyArrs. Issues zijn voor bugs en de roadmap.

Stuur je eerste pull request in

1. Zoek de module waar je wijziging bij hoort. De namen in Modules komen overeen met mapnamen, dus een verkeerde Discord-melding is een wijziging in alerts.

2. Maak de wijziging in app/backend/internal/<module>/ en app/frontend/src/lib/<module>/. Houd het bij één fix of één functie.

3. Bouw de web-app, daarna het programma, en probeer de wijziging in de browser. Zie Configuratie.

4. Voer de controles uit in Testen.

   Je ziet geen enkele fout.

5. Heb je een pagina gewijzigd, voer dan het end-to-end-project ervan uit, bijvoorbeeld npm --prefix app/frontend run e2e -- --project=movies.

6. Open de pull request. Koppel de issue, schrijf wat er is gewijzigd en hoe je het hebt getest, en voeg tests voor de wijziging toe of werk ze bij.

7. Bij je eerste pull request vraagt een bot je om de licentieovereenkomst voor bijdragers te ondertekenen. Antwoord met de ene zin waar hij om vraagt.

Opmerking

Je houdt het auteursrecht op je werk. Dankzij de overeenkomst kan HolyArrs worden aangeboden onder de AGPL-3.0 en onder een commerciële licentie. Wat is samengevoegd, blijft ook beschikbaar onder de AGPL-3.0. De tekst staat in .github/CLA.md.

Keuzes

Waar een wijziging heen gaat

Wijziging	Ga naar
Een nieuwe route	Modules
Een nieuwe module	Modules. Open eerst een issue
Een uitgestelde functie	Configuratie
Een versie	Versies maken. Alleen voor beheerders

Hoe een goede pull request eruitziet

• Schrijf commentaar dat zegt waarom de code doet wat hij doet. Geen roadmapnummers, datums, namen of gedachtestreepjes in commentaar.
• Laat de teksten van de app met rust, tenzij de issue over de tekst gaat.
• Laat paden van de API, veldnamen, instellingssleutels, tabelnamen en taaknamen die al zijn uitgebracht zoals ze zijn. Voeg toe, hernoem nooit.

Als het niet werkt

Symptoom. Een structuurcontrole mislukt. Oorzaak. De melding noemt het bestand en de regel. Oplossing. Verplaats de code, of geef gewone data door vanuit de hogere module. Zie Modules.

Symptoom. De web-app ziet er oud uit. Oorzaak. Het programma serveert de build die erin is ingebouwd. Oplossing. Bouw de web-app opnieuw voordat je het programma bouwt.

Symptoom. End-to-end-tests kunnen niet starten. Oorzaak. De testbrowser is niet geïnstalleerd. Oplossing. Voer npx --prefix app/frontend playwright install chromium uit.

Voor gevorderden

Regels waaraan een pull request moet voldoen

• Een module praat met een andere module alleen via de service (Go) of de index.ts (web). Nooit via de store of de bestanden.
• SQL staat alleen in de store*.go-bestanden van een module, voor de eigen tabellen van die module.
• Een webonderdeel komt alleen in lib/ui als 2 of meer modules het gebruiken.
• Geen pakketten met de namen util, common, shared of helpers.
• Elke aanroep naar buiten gaat via core/outbound.

Tests controleren deze regels, dus een verkeerde import laat de build mislukken. De volledige lijst en de namen van de controles staan in Modules.

Wat CI draait

Job	Draait
Web	check, lint, test, build en de end-to-end-suite
Go	go build, go vet en go test -timeout 60m ./... op amd64 en arm64, native en onder emulatie
Race	go test -race ./...
Contract	De openapi.json-vergelijking, scopecontroles op elke route, de downloadersuite
Fout en schaal	Runs met crashes, trage schrijfacties, een slechte externe dienst en geheugen
Image	Een ontwikkelimage wordt gebouwd, start en meldt zijn versie

Details over de lange runs staan in Testen.

Gerelateerde pagina’s

• Configuratie
• Testen
• Architectuur