مشارکت

راه‌اندازی

در جای درست یک تغییر کوچک بدهید و آن را به‌صورت pull request بفرستید.

پیش از شروع

اول یک issue باز کنید، یا زیر issue موجود نظر بدهید. بگویید چه چیزی را می‌خواهید تغییر دهید و چرا.
منتظر پاسخ بمانید، تا چیزی نسازید که قرار نیست merge شود.
راه‌اندازی را تمام کنید تا بتوانید HolyArrs را بسازید و اجرا کنید.

پرسش‌ها را در Discord بپرسید. ایده‌ها به r/HolyArrs می‌روند. issueها برای باگ‌ها و نقشهٔ راه هستند.

اولین pull request خود را بفرستید

ماژولی را پیدا کنید که تغییر شما به آن تعلق دارد. نام‌ها در ماژول‌ها با نام پوشه‌ها یکی است، پس اعلان اشتباه Discord تغییری در alerts است.
تغییر را در app/backend/internal/<module>/ و app/frontend/src/lib/<module>/ بدهید. آن را به یک رفع مشکل یا یک ویژگی محدود نگه دارید.
اول برنامهٔ وب و بعد برنامه را بسازید و تغییر را در مرورگر امتحان کنید. راه‌اندازی را ببینید.
بررسی‌های آزمایش را اجرا کنید.

نباید هیچ خطایی ببینید.
اگر صفحه‌ای را تغییر داده‌اید، پروژهٔ end-to-end آن را اجرا کنید، برای مثال npm --prefix app/frontend run e2e -- --project=movies.
pull request را باز کنید. issue را پیوند دهید، بگویید چه چیزی تغییر کرده و چطور آزمایشش کرده‌اید، و برای تغییر آزمایش اضافه یا به‌روز کنید.
در اولین pull request شما، یک ربات از شما می‌خواهد توافق‌نامهٔ مجوز مشارکت‌کننده را امضا کنید. با همان یک جمله‌ای که می‌خواهد پاسخ بدهید.

گزینه‌ها

تغییر کجا می‌رود

تغییر	بروید به
یک مسیر جدید	ماژول‌ها
یک ماژول جدید	ماژول‌ها. اول issue باز کنید
یک ویژگی نگه‌داشته‌شده	راه‌اندازی
یک نسخهٔ منتشرشده	انتشار نسخه. فقط برای نگه‌دارندگان

یک pull request خوب چه شکلی است

کامنت‌ها را طوری بنویسید که بگویند چرا کد این کار را می‌کند. در کامنت‌ها شمارهٔ نقشهٔ راه، تاریخ، نام یا em dash نگذارید.
عبارت‌های برنامه را دست نزنید، مگر اینکه issue دربارهٔ عبارت‌ها باشد.
مسیرهای API، نام فیلدها، کلیدهای تنظیمات، نام جدول‌ها و نام کارهایی که منتشر شده‌اند را همان‌طور نگه دارید. اضافه کنید، هرگز تغییر نام ندهید.

اگر کار نکرد

نشانه. یک بررسی ساختار رد می‌شود. علت. پیام نام فایل و قانون را می‌گوید. راه‌حل. کد را جابه‌جا کنید، یا داده‌های ساده را از ماژول بالاتر پایین بدهید. ماژول‌ها را ببینید.

نشانه. برنامهٔ وب قدیمی به نظر می‌رسد. علت. برنامه همان بیلدی را ارائه می‌کند که در خودش تعبیه کرده است. راه‌حل. پیش از برنامه، دوباره برنامهٔ وب را بسازید.

نشانه. آزمایش‌های end-to-end شروع نمی‌شوند. علت. مرورگر آزمایش نصب نیست. راه‌حل. npx --prefix app/frontend playwright install chromium را اجرا کنید.

برای حرفه‌ای‌ها

قوانینی که یک pull request باید رعایت کند

یک ماژول فقط از راه سرویسش (Go) یا index.ts آن (وب) با ماژول دیگر حرف می‌زند. هرگز از راه store یا فایل‌های آن.
SQL فقط در فایل‌های store*.go یک ماژول است، آن هم روی جدول‌های خود همان ماژول.
یک بخش وب فقط وقتی به lib/ui می‌رود که 2 ماژول یا بیشتر از آن استفاده کنند.
بستهٔ util، common، shared یا helpers نداریم.
هر درخواست به بیرون از core/outbound می‌گذرد.

آزمایش‌ها این قوانین را بررسی می‌کنند، پس import اشتباه بیلد را رد می‌کند. فهرست کامل و نام بررسی‌ها در ماژول‌ها است.

CI چه چیزی را اجرا می‌کند

کار	اجرا می‌کند
Web	`check`، `lint`، `test`، `build` و مجموعهٔ end-to-end
Go	`go build`، `go vet` و `go test -timeout 60m ./...` روی `amd64` و `arm64`، به‌صورت بومی و زیر شبیه‌ساز
Race	`go test -race ./...`
Contract	تطبیق `openapi.json`، بررسی scope روی هر مسیر، مجموعهٔ آزمایش دانلودر
Fault and scale	اجراهای کرش، نوشتن کند، سرویس بیرونی خراب و حافظه
Image	یک ایمیج توسعه بیلد می‌شود، شروع می‌شود و نسخهٔ خود را گزارش می‌دهد

جزئیات اجراهای طولانی در آزمایش است.

صفحه‌های مرتبط

HolyArrs رایگان است. اگر در وقتتان صرفه‌جویی کرد، در GitHub به آن ستاره بدهید، حمایت مالی کنید یا برای من یک قهوه بخرید.