Принос

Направи една малка промяна на правилното място и я изпрати като pull request.

Преди да започнеш

• Първо отвори проблем (issue) или коментирай съществуващ. Кажи какво искаш да промениш и защо.
• Изчакай отговор, за да не направиш нещо, което няма да бъде прието.
• Мини през Настройка, за да можеш да build-неш и да пуснеш HolyArrs.

Въпросите отиват в Discord. Идеите отиват в r/HolyArrs. Issues са за грешки и за пътната карта.

Изпрати първия си pull request

1. Намери модула, към който принадлежи промяната ти. Имената в Модули съвпадат с имената на папките, така че грешно известие в Discord е промяна в alerts.

2. Направи промяната в app/backend/internal/<module>/ и app/frontend/src/lib/<module>/. Дръж се в рамките на една поправка или една функция.

3. Build-ни уеб приложението, после програмата, и пробвай промяната в браузъра. Виж Настройка.

4. Пусни проверките от Тестване.

   Не трябва да виждаш нито един провал.

5. Ако си променил страница, пусни нейния end-to-end проект, например npm --prefix app/frontend run e2e -- --project=movies.

6. Отвори pull request. Свържи проблема, кажи какво си променил и как си го тествал, и добави или обнови тестове за промяната.

7. При първия ти pull request бот ще те помоли да подпишеш споразумението за лиценз на сътрудника. Отговори с едното изречение, което иска.

Note

Запазваш авторските права върху работата си. Споразумението позволява HolyArrs да се предлага под AGPL-3.0 и под търговски лиценз. Всичко, което е прието, остава достъпно и под AGPL-3.0. Текстът е в .github/CLA.md.

Възможности

Къде отива промяната

Промяна	Иди на
Нов маршрут	Модули
Нов модул	Модули. Първо отвори проблем
Задържана функция	Настройка
Версия	Публикуване на версии. Само за поддържащите

Как изглежда добрият pull request

• Пиши коментари, които казват защо кодът прави това, което прави. Без номера от пътната карта, дати, имена и дълги тирета в коментарите.
• Не пипай текстовете на приложението, освен ако проблемът не е за тях.
• Запази непроменени вече публикуваните API пътища, имена на полета, ключове на настройки, имена на таблици и имена на задачи. Добавяй, никога не преименувай.

Ако не работи

Проблем. Проверка на структурата пада. Причина. Съобщението назовава файла и правилото. Решение. Премести кода или подай обикновени данни от по-горния модул. Виж Модули.

Проблем. Уеб приложението изглежда старо. Причина. Програмата сервира билда, който е вградила. Решение. Build-ни уеб приложението отново преди програмата.

Проблем. End-to-end тестовете не могат да стартират. Причина. Браузърът за тестове не е инсталиран. Решение. Изпълни npx --prefix app/frontend playwright install chromium.

За експерти

Правила, които един pull request трябва да спазва

• Един модул говори с друг модул само през неговата услуга (Go) или през неговия index.ts (уеб). Никога през неговото хранилище или файлове.
• SQL живее само във файловете store*.go на модула и то върху собствените му таблици.
• Уеб част отива в lib/ui само ако я ползват 2 или повече модула.
• Без пакети util, common, shared или helpers.
• Всяко извикване навън минава през core/outbound.

Тестове проверяват тези правила, така че грешен импорт чупи билда. Пълният списък и имената на проверките са в Модули.

Какво пуска 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, проверки на обхвата за всеки маршрут, пакета за програми за изтегляне
Fault and scale	Пускания със срив, бавен запис, лош външен сървър и памет
Image	Образ за разработка се build-ва, стартира и съобщава версията си

Подробности за дългите пускания има в Тестване.

Свързано

• Настройка
• Тестване
• Архитектура