Aller au contenu

Contribuer

Par où commencer quand vous voulez travailler sur le code d'Evey, et ce qu'une pull request doit passer. Les documents écrits pour les contributeurs sont conservés avec le code, sur GitHub, plutôt que sur ce site ; cette page y renvoie. Ils sont en anglais.

Par où commencer

Vous voulez Lisez
Construire et lancer Evey depuis les sources DEV.md
Connaître les règles d'une contribution : branches, commits, tests, l'accord de licence CONTRIBUTING.md
Vous repérer dans le code en une demi-heure Carte du code
Comprendre les couches et les contextes bornés Architecture
Suivre les conventions que le code utilise déjà Conventions de code
Travailler sur l'interface Système de design du frontend
Savoir pourquoi un choix structurel a été fait Décisions d'architecture
Publier une version Procédure de release

Pourquoi une décision d'architecture, et où

Chaque choix structurel - la disposition hexagonale, la portée des jetons de plugin, pourquoi l'installation tient en un seul fichier compose, comment un seul plan de lecture décide pour tous les clients - a sa décision d'architecture (ADR) : le contexte, les options pesées, ce qui a été choisi et ce que cela coûte. Elles sont conservées dans le dépôt, à côté du code qu'elles expliquent, et sont le point de départ avant de proposer de changer l'un de ces choix.

Avant d'ouvrir une pull request

  1. Lancez make pre-push : c'est le contrôle à passer, et il exécute en local les vérifications de la CI dans cet ordre : vet, recherche de vulnérabilités, build, tests unitaires avec -race, frontend (typage, lint, tests unitaires), analyse de sécurité, lint, gardes d'architecture, hygiène des commits, recherche de secrets, détection de rupture des proto, build depuis un checkout propre, les contrôles d'intégration du dépôt et du transcodage, et l'audit TV.
  2. Ajoutez des tests pour tout nouveau comportement et pour chaque correction de bug.
  3. Pour une contribution externe, acceptez une fois l'accord de licence de contribution : Evey est sous AGPL-3.0-or-later et peut aussi être proposé sous licence commerciale. Vous gardez le droit d'auteur sur votre travail.

Le contrôle ne construit ni l'image Docker ni les applications Android

Après avoir touché le Dockerfile ou du code Kotlin, construisez-les vous-même (docker build --target runtime, la tâche Gradle de release) avant de pousser.

Les problèmes de sécurité ne se signalent pas en public : écrivez à security@eveyproject.org (voir SECURITY.md).