1.9 KiB
Architecture Decision Records — gitea-dashboard
ADR-001 : Stack Python + requests + rich
Date : 2026-03-10 Statut : accepte
Contexte : Besoin d'un outil CLI de dashboard pour Gitea. Choix du langage et des librairies.
Decision : Python avec requests pour les appels API et rich pour le formatage terminal.
Consequences :
- Stack simple et maitrisee par l'utilisateur
- Pas de framework CLI lourd (argparse suffit si besoin)
- rich offre des tableaux et couleurs sans configuration complexe
- Dependance a requests (pas de client async, acceptable pour un affichage unique)
ADR-002 : 4 modules maximum (client, collector, display, cli)
Date : 2026-03-10 Statut : accepte
Contexte : Definir la granularite des modules Python pour un projet simple (dashboard CLI).
Decision : Limiter a 4 modules avec des responsabilites claires : client.py (API), collector.py (agregation), display.py (formatage), cli.py (entree).
Consequences :
- Separation des responsabilites sans over-engineering
- Chaque module est testable independamment
- Un fichier = une responsabilite = un jeu de tests
- Si le projet grandit, chaque module peut evoluer independamment
ADR-003 : Pas de parallelisation en v1
Date : 2026-03-10 Statut : accepte
Contexte : La collecte de donnees necessite N appels par repo (release + milestones). La parallelisation (ThreadPoolExecutor) est possible mais ajoute de la complexite.
Decision : V1 en sequentiel. La parallelisation est differee a v1.1+.
Consequences :
- Code plus simple a ecrire, deboguer et tester
- Temps de reponse acceptable pour < 20 repos (estimee < 10s)
- Pas de problemes de concurrence
- Facile a ajouter plus tard sans changer les interfaces (le collecteur est le seul point d'appel)