Участь у розробці

Зроби одну невелику зміну в потрібному місці й надішли її як pull request.

Перш ніж почати

• Спершу відкрий issue або напиши коментар до наявного. Розкажи, що хочеш змінити і навіщо.
• Дочекайся відповіді, щоб не робити те, що не приймуть.
• Пройди Налаштування, щоб могти зібрати й запустити HolyArrs.

Питання став у Discord. Ідеї — на r/HolyArrs. Issues — для багів і дорожньої карти.

Надішли свій перший pull request

1. Знайди модуль, до якого належить твоя зміна. Назви в розділі Модулі збігаються з назвами тек, тож хибне сповіщення в Discord — це зміна в alerts.

2. Зроби зміну в app/backend/internal/<module>/ і app/frontend/src/lib/<module>/. Обмежся одним виправленням або однією функцією.

3. Збери вебзастосунок, потім програму, і спробуй зміну в браузері. Дивись Налаштування.

4. Запусти перевірки зі сторінки Тестування.

   Збоїв бути не має.

5. Якщо ти змінив сторінку, запусти її наскрізний проєкт, наприклад npm --prefix app/frontend run e2e -- --project=movies.

6. Відкрий pull request. Додай посилання на issue, напиши, що змінилося і як ти це перевірив, та додай або онови тести для зміни.

7. У твоєму першому pull request бот попросить підписати ліцензійну угоду контриб’ютора. Відповідай одним реченням, яке він просить.

Заувага

Авторські права на твою роботу лишаються за тобою. Угода дозволяє пропонувати HolyArrs за ліцензією AGPL-3.0 і за комерційною ліцензією. Усе, що прийнято, також лишається доступним за AGPL-3.0. Текст лежить у .github/CLA.md.

Варіанти

Куди йде зміна

Зміна	Куди
Новий маршрут	Модулі
Новий модуль	Модулі. Спершу відкрий issue
Відкладена функція	Налаштування
Версія	Випуск версій. Лише для мейнтейнерів

Який вигляд має добрий pull request

• Пиши коментарі, які пояснюють, чому код робить саме так. У коментарях не має бути номерів із дорожньої карти, дат, імен і довгих тире.
• Не чіпай формулювання в застосунку, якщо issue не про формулювання.
• Не змінюй шляхи API, назви полів, ключі параметрів, назви таблиць і назви завдань, які вже вийшли. Додавай, ніколи не перейменовуй.

Якщо не працює

Ознака. Не проходить структурна перевірка. Причина. Повідомлення називає файл і правило. Рішення. Перенеси код або передай прості дані з вищого модуля. Дивись Модулі.

Ознака. Вебзастосунок має старий вигляд. Причина. Програма віддає збірку, яку вбудувала. Рішення. Збери вебзастосунок заново, перш ніж збирати програму.

Ознака. Наскрізні тести не запускаються. Причина. Не встановлено браузер для тестів. Рішення. Виконай 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.

Тести перевіряють ці правила, тож хибний імпорт ламає збірку. Повний список і назви перевірок — у розділі Модулі.

Що запускає CI

Завдання	Що виконує
Web	check, lint, test, build і набір наскрізних тестів
Go	go build, go vet і go test -timeout 60m ./... на amd64 та arm64, нативно й під емуляцією
Race	go test -race ./...
Contract	Збіг із openapi.json, перевірки доступу на кожному маршруті, набір тестів завантажувачів
Fault and scale	Запуски зі збоєм, повільним записом, поганим зовнішнім сервісом і навантаженням на пам’ять
Image	Тестовий образ збирається, запускається й повідомляє свою версію

Подробиці довгих запусків — у розділі Тестування.

Пов’язане

• Налаштування
• Тестування
• Архітектура