Prisidėjimas

Padaryk vieną mažą pakeitimą tinkamoje vietoje ir išsiųsk jį kaip pull request.

Prieš pradedant

• Pirmiausia atidaryk issue arba pakomentuok esamą. Parašyk, ką nori keisti ir kodėl.
• Palauk atsakymo, kad nepadarytum to, kas nebus priimta.
• Pabaik sąranką, kad galėtum sukompiliuoti ir paleisti HolyArrs.

Klausimus rašyk į Discord. Idėjas rašyk į r/HolyArrs. Issues skirti klaidoms ir planui.

Išsiųsk pirmą pull request

1. Rask modulį, kuriam tavo pakeitimas priklauso. Pavadinimai modulių puslapyje sutampa su aplankų pavadinimais, todėl blogas Discord pranešimas yra pakeitimas alerts modulyje.

2. Padaryk pakeitimą app/backend/internal/<module>/ ir app/frontend/src/lib/<module>/. Laikykis vieno pataisymo arba vienos funkcijos.

3. Sukompiliuok žiniatinklio programą, paskui programą, ir išbandyk pakeitimą naršyklėje. Žiūrėk sąranką.

4. Paleisk patikras iš testavimo puslapio.

   Turėtum pamatyti, kad nieko nenulūžo.

5. Jei pakeitei puslapį, paleisk jo end-to-end projektą, pavyzdžiui, npm --prefix app/frontend run e2e -- --project=movies.

6. Atidaryk pull request. Nurodyk issue, parašyk, kas pasikeitė ir kaip tai išbandei, ir pridėk ar atnaujink pakeitimo testus.

7. Per pirmą pull request botas paprašys pasirašyti bendradarbio licencijos sutartį. Atsakyk vienu sakiniu, kurio jis prašo.

Note

Tavo darbo autorių teisės lieka tau. Sutartis leidžia HolyArrs siūlyti pagal AGPL-3.0 ir pagal komercinę licenciją. Viskas, kas priimta, taip pat lieka prieinama pagal AGPL-3.0. Tekstas yra .github/CLA.md.

Pasirinkimai

Kur eina pakeitimas

Pakeitimas	Eik į
Naujas maršrutas	Moduliai
Naujas modulis	Moduliai. Pirmiausia atidaryk issue
Atidėta funkcija	Sąranka
Versija	Versijų išleidimas. Tik prižiūrėtojams

Koks yra geras pull request

• Komentarai turi sakyti, kodėl kodas daro tai, ką daro. Jokių plano numerių, datų, vardų ar ilgųjų brūkšnių komentaruose.
• Programos tekstų nelieski, nebent issue yra būtent apie tekstą.
• Išleistų API kelių, laukų pavadinimų, nustatymų raktų, lentelių pavadinimų ir užduočių pavadinimų nekeisk. Pridėk, bet niekada nepervadink.

Jei neveikia

Požymis. Struktūros patikra nepavyksta. Priežastis. Pranešime nurodytas failas ir taisyklė. Sprendimas. Perkelk kodą arba perduok paprastus duomenis iš aukštesnio modulio. Žiūrėk modulius.

Požymis. Žiniatinklio programa atrodo sena. Priežastis. Programa aptarnauja build, kurį į save įdėjo. Sprendimas. Prieš programą dar kartą sukompiliuok žiniatinklio programą.

Požymis. End-to-end testai nepasileidžia. Priežastis. Neįdiegta testų naršyklė. Sprendimas. Vykdyk npx --prefix app/frontend playwright install chromium.

Pažengusiems

Taisyklės, kurių pull request turi laikytis

• Modulis kalbasi su kitu moduliu tik per jo servisą (Go) arba jo index.ts (žiniatinklis). Niekada per jo store ar jo failus.
• SQL gyvena tik modulio store*.go failuose ir tik virš to modulio lentelių.
• Žiniatinklio dalis keliama į lib/ui tik tada, kai ją naudoja 2 ar daugiau modulių.
• Jokių util, common, shared ar helpers paketų.
• Kiekvienas išorinis kreipinys eina per core/outbound.

Testai tikrina šias taisykles, todėl blogas importas nutraukia build. Pilnas sąrašas ir patikrų pavadinimai yra modulių puslapyje.

Ką paleidžia CI

Užduotis	Paleidžia
Web	check, lint, test, build ir end-to-end rinkinį
Go	go build, go vet ir go test -timeout 60m ./... su amd64 ir arm64, natūraliai ir per emuliaciją
Race	go test -race ./...
Contract	openapi.json atitikimą, teisių patikras kiekvienam maršrutui, atsisiuntimo programų rinkinį
Fault and scale	Strigčių, lėto rašymo, blogos išorinės paslaugos ir atminties bandymus
Image	Kūrimo image sukompiliuojamas, paleidžiamas ir parodo savo versiją

Ilgų bandymų detalės yra testavimo puslapyje.

Susiję puslapiai

• Sąranka
• Testavimas
• Architektūra