Mitwirken

Einrichtung

Mach eine kleine Änderung an der richtigen Stelle und schick sie als Pull Request.

Bevor du beginnst

Öffne zuerst ein Issue oder kommentiere ein bestehendes. Schreib, was du ändern willst und warum.
Warte auf eine Antwort, damit du nichts baust, das nicht gemergt wird.
Schließe die Einrichtung ab, damit du HolyArrs bauen und starten kannst.

Fragen gehören auf Discord. Ideen gehören nach r/HolyArrs. Issues sind für Fehler und die Roadmap da.

Deinen ersten Pull Request schicken

Finde das Modul, in das deine Änderung gehört. Die Namen unter Module entsprechen den Ordnernamen. Eine falsche Discord-Benachrichtigung ist also eine Änderung in alerts.
Mach die Änderung in app/backend/internal/<module>/ und app/frontend/src/lib/<module>/. Bleib bei einer Fehlerbehebung oder einer Funktion.
Baue erst die Web-App, dann das Programm, und probiere die Änderung im Browser aus. Siehe Einrichtung.
Führe die Prüfungen unter Testen aus.

Du solltest keinen Fehlschlag sehen.
Wenn du eine Seite geändert hast, führe ihr End-to-End-Projekt aus, zum Beispiel npm --prefix app/frontend run e2e -- --project=movies.
Öffne den Pull Request. Verlinke das Issue, schreib, was sich geändert hat und wie du es getestet hast, und ergänze oder aktualisiere Tests für die Änderung.
Bei deinem ersten Pull Request bittet dich ein Bot, die Lizenzvereinbarung für Mitwirkende zu unterschreiben. Antworte mit dem einen Satz, den er verlangt.

Optionen

Wohin eine Änderung gehört

Änderung	Gehe zu
Eine neue Route	Module
Ein neues Modul	Module. Öffne zuerst ein Issue
Eine zurückgestellte Funktion	Einrichtung
Eine Version	Version veröffentlichen. Nur für Maintainer

Wie ein guter Pull Request aussieht

Schreib Kommentare, die sagen, warum der Code tut, was er tut. Keine Roadmap-Nummern, Daten, Namen oder Geviertstriche in Kommentaren.
Lass die Texte der App in Ruhe, außer das Issue dreht sich um Texte.
Lass veröffentlichte API-Pfade, Feldnamen, Einstellungsschlüssel, Tabellennamen und Aufgabennamen, wie sie sind. Ergänze, benenne nie um.

Wenn es nicht funktioniert

Symptom. Eine Strukturprüfung schlägt fehl. Ursache. Die Meldung nennt die Datei und die Regel. Lösung. Verschiebe den Code oder reiche einfache Daten aus dem höheren Modul herein. Siehe Module.

Symptom. Die Web-App sieht alt aus. Ursache. Das Programm liefert den Build aus, den es eingebettet hat. Lösung. Baue die Web-App noch einmal, bevor du das Programm baust.

Symptom. Die End-to-End-Tests starten nicht. Ursache. Der Testbrowser ist nicht installiert. Lösung. Führe npx --prefix app/frontend playwright install chromium aus.

Für Fortgeschrittene

Regeln, die ein Pull Request einhalten muss

Ein Modul spricht mit einem anderen Modul nur über dessen Service (Go) oder dessen index.ts (Web). Nie über dessen Store oder dessen Dateien.
SQL steht nur in den store*.go-Dateien eines Moduls und greift nur auf die eigenen Tabellen dieses Moduls zu.
Ein Web-Baustein kommt nur dann nach lib/ui, wenn 2 oder mehr Module ihn verwenden.
Keine Pakete namens util, common, shared oder helpers.
Jeder Aufruf nach außen läuft über core/outbound.

Tests prüfen diese Regeln, ein falscher Import lässt also den Build scheitern. Die ganze Liste und die Namen der Prüfungen stehen unter Module.

Was CI ausführt

CI-Job	Führt aus
Web	`check`, `lint`, `test`, `build` und die End-to-End-Suite
Go	`go build`, `go vet` und `go test -timeout 60m ./...` auf `amd64` und `arm64`, nativ und unter Emulation
Race	`go test -race ./...`
Vertrag	Den Abgleich mit `openapi.json`, Berechtigungsprüfungen für jede Route, die Downloader-Suite
Fehler und Last	Läufe mit Absturz, langsamem Schreiben, fehlerhaftem externem Dienst und Arbeitsspeicher
Image	Ein Entwicklungs-Image wird gebaut, startet und meldet seine Version

Einzelheiten zu den langen Läufen stehen unter Testen.