Contribuer

Configuration

Faites un petit changement au bon endroit et envoyez-le sous forme de pull request.

Avant de commencer

Ouvrez d’abord une issue, ou commentez-en une qui existe. Dites ce que vous voulez changer et pourquoi.
Attendez une réponse, pour ne pas développer quelque chose qui ne sera pas fusionné.
Terminez la Configuration pour pouvoir compiler et lancer HolyArrs.

Les questions vont sur Discord. Les idées vont sur r/HolyArrs. Les issues servent aux bugs et à la feuille de route.

Envoyer votre première pull request

Trouvez le module concerné par votre changement. Les noms dans Modules sont ceux des dossiers : une alerte Discord incorrecte, c’est un changement dans alerts.
Faites le changement dans app/backend/internal/<module>/ et app/frontend/src/lib/<module>/. Limitez-vous à une correction ou à une fonctionnalité.
Compilez l’application web, puis le programme, et essayez le changement dans le navigateur. Voir Configuration.
Lancez les contrôles de Tests.

Vous ne devriez voir aucun échec.
Si vous avez modifié une page, lancez son projet de bout en bout, par exemple npm --prefix app/frontend run e2e -- --project=movies.
Ouvrez la pull request. Liez l’issue, dites ce qui a changé et comment vous l’avez testé, et ajoutez ou mettez à jour les tests du changement.
À votre première pull request, un bot vous demande de signer l’accord de licence de contributeur. Répondez avec la phrase qu’il demande.

Options

Où va un changement

Changement	Allez voir
Une nouvelle route	Modules
Un nouveau module	Modules. Ouvrez d’abord une issue
Une fonctionnalité en réserve	Configuration
Une version	Publier une version. Réservé aux mainteneurs

À quoi ressemble une bonne pull request

Écrivez des commentaires qui disent pourquoi le code fait ce qu’il fait. Pas de numéros de feuille de route, de dates, de noms ni de tirets cadratins dans les commentaires.
Ne touchez pas aux textes de l’application, sauf si l’issue porte sur les textes.
Gardez tels quels les chemins d’API, les noms de champs, les clés de paramètres, les noms de tables et les noms de tâches déjà publiés. Ajoutez, ne renommez jamais.

Si ça ne fonctionne pas

Symptôme. Un contrôle de structure échoue. Cause. Le message indique le fichier et la règle. Solution. Déplacez le code, ou passez des données simples depuis le module supérieur. Voir Modules.

Symptôme. L’application web a l’air ancienne. Cause. Le programme sert le build qu’il a embarqué. Solution. Compilez de nouveau l’application web avant le programme.

Symptôme. Les tests de bout en bout ne démarrent pas. Cause. Le navigateur de test n’est pas installé. Solution. Lancez npx --prefix app/frontend playwright install chromium.

Pour les experts

Les règles qu'une pull request doit respecter

Un module parle à un autre module seulement par son service (Go) ou son index.ts (web). Jamais par son store ni par ses fichiers.
Le SQL vit seulement dans les fichiers store*.go d’un module, sur les tables de ce module.
Un composant web va dans lib/ui seulement quand 2 modules ou plus l’utilisent.
Pas de paquets util, common, shared ni helpers.
Chaque appel vers l’extérieur passe par core/outbound.

Des tests vérifient ces règles, donc un mauvais import fait échouer le build. La liste complète et les noms des contrôles sont dans Modules.

Ce que lance la CI

Tâche	Lance
Web	`check`, `lint`, `test`, `build` et la suite de bout en bout
Go	`go build`, `go vet` et `go test -timeout 60m ./...` sur `amd64` et `arm64`, en natif et en émulation
Race	`go test -race ./...`
Contrat	La correspondance avec `openapi.json`, les contrôles de portée sur chaque route, la suite des clients de téléchargement
Pannes et charge	Des tests de plantage, d’écriture lente, de service extérieur défaillant et de mémoire
Image	Une image de développement se construit, démarre et indique sa version

Le détail des tests longs est dans Tests.

Voir aussi

HolyArrs est gratuit. S'il vous a fait gagner du temps, mettez-lui une étoile sur GitHub, sponsorisez-le ou offrez-moi un café.