Cum contribui

Fă o schimbare mică în locul potrivit și trimite-o ca pull request.

Înainte să începi

• Deschide mai întâi o problemă (issue) sau comentează la una existentă. Spune ce vrei să schimbi și de ce.
• Așteaptă un răspuns, ca să nu construiești ceva ce nu va fi acceptat.
• Termină Configurare, ca să poți construi și rula HolyArrs.

Întrebările merg pe Discord. Ideile merg pe r/HolyArrs. Problemele (issues) sunt pentru bug-uri și foaia de parcurs.

Trimite primul pull request

1. Găsește modulul în care intră schimbarea ta. Numele din Module se potrivesc cu numele dosarelor, așa că o alertă Discord greșită înseamnă o schimbare în alerts.

2. Fă schimbarea în app/backend/internal/<module>/ și în app/frontend/src/lib/<module>/. Rămâi la o singură reparație sau o singură funcție.

3. Construiește aplicația web, apoi programul, și încearcă schimbarea în browser. Vezi Configurare.

4. Rulează verificările din Testare.

   Ar trebui să nu vezi nicio eroare.

5. Dacă ai schimbat o pagină, rulează proiectul ei end-to-end, de exemplu npm --prefix app/frontend run e2e -- --project=movies.

6. Deschide pull request-ul. Leagă problema, spune ce s-a schimbat și cum ai testat, și adaugă sau actualizează testele pentru schimbare.

7. La primul tău pull request, un bot îți cere să semnezi acordul de licență pentru contribuitori. Răspunde cu propoziția pe care o cere.

Mențiune

Drepturile de autor pentru munca ta rămân ale tale. Acordul permite ca HolyArrs să fie oferit sub AGPL-3.0 și sub o licență comercială. Tot ce se îmbină rămâne disponibil și sub AGPL-3.0. Textul e în .github/CLA.md.

Alegeri

Unde merge o schimbare

Schimbare	Mergi la
O rută nouă	Module
Un modul nou	Module. Deschide mai întâi o problemă
O funcție reținută	Configurare
O versiune	Publicarea versiunilor. Doar pentru mentenanți

Cum arată un pull request bun

• Scrie comentarii care spun de ce face codul ce face. Fără numere din foaia de parcurs, date, nume sau liniuțe lungi (em dash) în comentarii.
• Lasă în pace textele aplicației, afară de cazul în care problema e despre texte.
• Păstrează cum sunt căile API, numele câmpurilor, cheile setărilor, numele tabelelor și numele sarcinilor deja publicate. Adaugă, nu redenumi niciodată.

Dacă nu merge

Simptom. O verificare de structură eșuează. Cauză. Mesajul numește fișierul și regula. Soluție. Mută codul sau trimite date simple din modulul de sus. Vezi Module.

Simptom. Aplicația web arată veche. Cauză. Programul servește build-ul pe care l-a inclus. Soluție. Construiește din nou aplicația web înaintea programului.

Simptom. Testele end-to-end nu pornesc. Cauză. Browserul de test nu e instalat. Soluție. Rulează npx --prefix app/frontend playwright install chromium.

Pentru experți

Reguli pe care trebuie să le respecte un pull request

• Un modul vorbește cu alt modul doar prin serviciul lui (Go) sau prin index.ts (web). Niciodată prin depozitul sau fișierele lui.
• SQL stă doar în fișierele store*.go ale unui modul, pentru tabelele proprii ale acelui modul.
• O parte web intră în lib/ui doar când o folosesc 2 sau mai multe module.
• Fără pachete util, common, shared sau helpers.
• Orice apel spre exterior trece prin core/outbound.

Testele verifică aceste reguli, așa că un import greșit oprește build-ul. Lista completă și numele verificărilor sunt în Module.

Ce rulează CI

Sarcină	Rulează
Web	check, lint, test, build și suita end-to-end
Go	go build, go vet și go test -timeout 60m ./... pe amd64 și arm64, nativ și în emulare
Race	go test -race ./...
Contract	Potrivirea cu openapi.json, verificări de scop pe fiecare rută, suita pentru programele de descărcare
Defecte și scară	Rulări cu oprire forțată, scriere lentă, serviciu extern defect și memorie
Imagine	O imagine de dezvoltare se construiește, pornește și raportează versiunea

Detaliile rulărilor lungi sunt în Testare.

Vezi și

• Configurare
• Testare
• Arhitectura