93 lines
4.5 KiB
Markdown
93 lines
4.5 KiB
Markdown
# Analyse v1.3.0 — gitea-dashboard
|
|
|
|
**Date** : 2026-03-12
|
|
**Track** : minor
|
|
**Issues** : #11, #12, #13, #14, #15 (5/5 fermees)
|
|
|
|
## Metriques
|
|
|
|
| Metrique | v1.2.0 | v1.3.0 | Delta | Seuil | Alerte |
|
|
|----------|--------|--------|-------|-------|--------|
|
|
| Modules source | 7 | 7 | 0 | — | — |
|
|
| Lignes source | ~530 | 664 | +25% | — | — |
|
|
| Tests | 88 | 122 | +34 (+39%) | +50% | non |
|
|
| LOC tests | ~1300 | 1706 | +31% | — | — |
|
|
| Couverture | 93% | 99% | +6% | -5% | non |
|
|
| Dependances | 2 | 2 | 0 | +5 | non |
|
|
| Audit initial | 81 (reviewer) / 87 (guardian) | — | — | — | — |
|
|
| Audit final | 100 | 100 | 0 | — | — |
|
|
| Rounds audit | 3 | 2 | -1 | — | — |
|
|
|
|
### Seuils d'alerte : tous respectes
|
|
|
|
- Tests +39% < seuil +50% : aucune action requise
|
|
- Dependances stables (0 ajout)
|
|
- Couverture en hausse (+6%) : progression notable, pas d'alerte
|
|
|
|
## Chronologie
|
|
|
|
| Etape | Duree estimee | Notes |
|
|
|-------|--------------|-------|
|
|
| 6 Plan | rapide | architect, 3 phases, ADR-009/010/011 |
|
|
| 7 Dev | moyen | orchestrator, 3 commits (1/phase), 5 fichiers modifies, 30 nouveaux tests |
|
|
| 8 Audit | moyen | 2 rounds (81→100), 3 corrections (Retry-After cap, fallback, test) |
|
|
| 9 Smoke | rapide | 8/8 E2E, --health OK, description OK, JSON pipe OK |
|
|
| 10 Docs | fusionne avec 11 | — |
|
|
| 11 Release | rapide | lightweight, tag v1.3.0 |
|
|
| 12 Deploy | skip | CLI local |
|
|
| 13 Retro | rapide | metriques + analyse |
|
|
|
|
## Findings d'audit corriges
|
|
|
|
1. **Retry-After cap** : le header `Retry-After` n'etait pas plafonné, permettant des attentes
|
|
arbitrairement longues — cap ajouté à 30 secondes
|
|
2. **Retry-After fallback** : les dates HTTP (format RFC 2822) n'etaient pas gérées, entraînant
|
|
une exception silencieuse — fallback sur backoff exponentiel ajouté
|
|
3. **Test Retry-After** : absence de test couvrant le chemin fallback — test ajouté
|
|
|
|
## Decisions notables
|
|
|
|
- **ADR-009** : gestion HTTP 429 avec `Retry-After` — respect du rate limiting Gitea,
|
|
cap à 30 s pour eviter des blocages indefinis
|
|
- **ADR-010** : colonne "Description" avec troncature à 40 caractères et option `--no-desc` —
|
|
compromis lisibilité/densité d'information
|
|
- **ADR-011** : sanitisation des caractères de contrôle JSON dans `exporter.py` —
|
|
robustesse face aux descriptions de repos non conformes
|
|
|
|
## Ce qui a bien fonctionne
|
|
|
|
- **Orchestrateur 3 phases** : la decomposition en phases distinctes (retry, description, edge
|
|
cases) a produit 3 commits propres et lisibles, sans contamination entre les fonctionnalites
|
|
- **Audit en 2 rounds** : le score initial de 81/87 a ete corrige en un seul cycle, contre
|
|
3 rounds pour v1.2.0 — signe que la qualite initiale du code s'améliore
|
|
- **Couverture 99%** : niveau exceptionnel atteint grace aux 30 tests edge cases (#13) —
|
|
les branches de formatage de display.py, problematiques en v1.2.0 (86%), sont desormais couvertes
|
|
- **--health integre naturellement** : la commande s'insere dans le flux CLI existant sans
|
|
modifier l'architecture (pas de nouveau module)
|
|
- **8/8 smoke tests** : pas de regression, tous les scenarios E2E valides du premier coup
|
|
|
|
## Ce qui peut etre ameliore
|
|
|
|
- **Score initial 81** (reviewer) : bien que corrige rapidement, le score de depart reste en
|
|
dessous du seuil optimal. L'orchestrateur devrait integrer une auto-review avant livraison
|
|
- **Fusion 10+11** : recurrente depuis v1.2.0 — si c'est systematique sur ce projet, l'envisager
|
|
comme convention plutot que comme exception
|
|
- **LOC tests / LOC source = 2.6x** : le ratio tests/source continue de croitre (+31% vs +25%)
|
|
— pas alarmant mais a surveiller pour eviter une dette de maintenance des tests
|
|
|
|
## Recommandations pour v1.4.0
|
|
|
|
1. **Parallelisation API** (ADR-003, dette documentee depuis v1.2.0) : remplacer les 3 appels
|
|
sequentiels par repo par des appels concurrents (`concurrent.futures.ThreadPoolExecutor`) —
|
|
gain de performance significatif sur les instances avec de nombreux repos
|
|
2. **Export CSV** : demande logique apres l'export JSON, meme architecture dans `exporter.py`
|
|
3. **Cache API local** : eviter les requetes repetees pour des donnees stables (releases, descriptions)
|
|
4. **Auto-review orchestrateur** : ajouter une passe reviewer apres dev avant audit formel,
|
|
pour reduire le nombre de rounds et partir d'un score initial plus eleve
|
|
|
|
## Conclusion
|
|
|
|
Version v1.3.0 livree avec les 5 fonctionnalites/corrections prevues. Audit final 100/100.
|
|
Le cycle a ete le plus efficace depuis v1.0.0 : 2 rounds d'audit seulement, 8/8 smoke tests,
|
|
couverture a 99%. La dette technique (N+1 API) reste la seule priorite ouverte pour v1.4.0.
|