Þátttaka

Gerðu eina litla breytingu á réttum stað og sendu hana sem pull request.

Áður en þú byrjar

• Opnaðu fyrst issue, eða skrifaðu athugasemd við issue sem er til. Segðu hverju þú vilt breyta og hvers vegna.
• Bíddu eftir svari, svo þú smíðir ekki eitthvað sem verður ekki tekið inn.
• Kláraðu Uppsetning svo þú getir smíðað og keyrt HolyArrs.

Spurningar fara á Discord. Hugmyndir fara á r/HolyArrs. Issues eru fyrir villur og vegvísinn.

Sendu fyrsta pull request

1. Finndu eininguna sem breytingin á heima í. Nöfnin í Einingar passa við möppunöfn, svo röng Discord-tilkynning er breyting í alerts.

2. Gerðu breytinguna í app/backend/internal/<module>/ og app/frontend/src/lib/<module>/. Haltu þig við eina lagfæringu eða einn eiginleika.

3. Smíðaðu vefforritið, svo forritið, og prófaðu breytinguna í browser. Sjá Uppsetning.

4. Keyrðu athuganirnar í Prófanir.

   Þú ættir ekki að sjá neina villu.

5. Ef þú breyttir síðu skaltu keyra end-to-end verkefni hennar, til dæmis npm --prefix app/frontend run e2e -- --project=movies.

6. Opnaðu pull request. Tengdu issue, segðu hverju var breytt og hvernig þú prófaðir það, og bættu við eða uppfærðu próf fyrir breytinguna.

7. Í fyrsta pull request biður bot þig um að skrifa undir samning um höfundarleyfi framlaga (CLA). Svaraðu með einu setningunni sem hann biður um.

Note

Þú heldur höfundarréttinum að verkinu þínu. Samningurinn gerir HolyArrs kleift að vera í boði undir AGPL-3.0 og undir viðskiptaleyfi. Allt sem er tekið inn er áfram í boði undir AGPL-3.0 líka. Textinn er í .github/CLA.md.

Valkostir

Hvert breytingin fer

Breyting	Farðu í
Ný leið	Einingar
Ný eining	Einingar. Opnaðu fyrst issue
Frestaður eiginleiki	Uppsetning
Ný útgáfa	Útgáfa. Aðeins fyrir umsjónarmenn

Hvernig góður pull request lítur út

• Skrifaðu athugasemdir sem segja hvers vegna kóðinn gerir það sem hann gerir. Engin vegvísanúmer, dagsetningar, nöfn eða em-strik í athugasemdum.
• Láttu orðalag forritsins í friði nema issue snúist um orðalag.
• Haltu birtum API-slóðum, heitum reita, stillingalyklum, töfluheitum og verkefnaheitum óbreyttum. Bættu við, endurnefndu aldrei.

Ef það virkar ekki

Einkenni. Byggingarathugun fellur. Orsök. Skilaboðin nefna skrána og regluna. Lausn. Færðu kóðann, eða sendu hrein gögn inn frá efri einingunni. Sjá Einingar.

Einkenni. Vefforritið lítur út fyrir að vera gamalt. Orsök. Forritið sýnir vefútgáfuna sem var innbyggð í það. Lausn. Smíðaðu vefforritið aftur áður en þú smíðar forritið.

Einkenni. End-to-end prófin geta ekki ræst. Orsök. Browser fyrir prófin er ekki uppsettur. Lausn. Keyrðu npx --prefix app/frontend playwright install chromium.

Fyrir sérfræðinga

Reglur sem pull request þarf að halda

• Eining talar við aðra einingu aðeins í gegnum þjónustu hennar (Go) eða index.ts hennar (vefur). Aldrei í gegnum store hennar eða skrár.
• SQL er aðeins í store*.go skrám einingar, yfir töflur þeirrar einingar.
• Vefhluti fer í lib/ui aðeins þegar 2 eða fleiri einingar nota hann.
• Engir util, common, shared eða helpers pakkar.
• Hvert utanaðkomandi kall fer í gegnum core/outbound.

Próf athuga þessar reglur, svo röng innflutningslína fellir smíðina. Allur listinn og nöfn athugananna eru í Einingar.

Hvað CI keyrir

Verkefni	Keyrir
Web	check, lint, test, build og end-to-end prófin
Go	go build, go vet og go test -timeout 60m ./... á amd64 og arm64, bæði beint og í hermun
Race	go test -race ./...
Contract	Samsvörun við openapi.json, heimildaathuganir á hverri leið, niðurhalsforritaprófin
Fault and scale	Keyrslur með hruni, hægri skrift, bilaðri utanaðkomandi þjónustu og minni
Image	Þróunar-image smíðast, ræsist og gefur upp útgáfu sína

Nánar um löngu keyrslurnar er í Prófanir.

Tengt efni

• Uppsetning
• Prófanir
• Arkitektúr