Authelia est une solution open-source de pointe pour l'authentification unique (SSO) et le multi-facteur (MFA). Maintenir un tel projet nécessite une structure de collaboration rigoureuse. Ce guide détaille les processus de gestion des tickets (Issues) et d'intégration de code (Pull Requests) pour permettre aux contributeurs de participer efficacement à l'évolution du projet.
Gestion et cycle de vie des Issues
Le projet Authelia catégorise les tickets principalement en deux groupes afin d'optimiser le temps de traitement des mainteneurs.
| Type de ticket | Description | Prérequis indispensables |
|---|---|---|
| Signalement de bogue | Dysfonctionnement ou erreur de performance. | Logs, environnement complet, étapes de reproduction. |
| Demande de fonctionnnalité | Suggestion d'amélioration ou nouvel outil. | Cas d'usage précis et bénéfices attendus. |
Avant d'ouvrir un ticket, il est impératif de vérifier si le problème n'a pas déjà été signalé et de s'assurer que le comportement observé ne provient pas d'une mauvaise configuration documentée.
Niveaux de priorité
| P0 - Critique : Vulnérabilités de sécurité ou perte de données. Réponse sous 24h. | P1 - Haute : Fonctionnalités majeures hors service. Réponse sous 72h. | P2 - Moyenne : Défaut mineur n'empêchant pas l'utilisation globale. | P3 - Basse : Optimisations et suggestions esthétiques.
Processus de soumission des Pull Requests (PR)
Pour garantir la stabilité d'Authelia, chaque contribution doit suivre un protocole strict de développement et de validation.
Configuration de l'environnement de développement
Le projet s'appuie sur une pile technologique moderne. Voici les dépendances nécessaires pour initialiser votre espace de travail :
# Vérification des outils requis
# Go (v1.24.3+), Node.js (v22.15.0+), pnpm (v10.10.0+)
# Docker & Docker Compose pour les tests d'intégration
# Initialisation du dépôt
git clone https://github.com/authelia/authelia.git
cd authelia
./scripts/bootstrap.sh # Préparation de l'environnement local
Standardisation des messages de validation (Commit)
Authelia suit la convention Conventional Commits pour générer automatiquement les journaux de modifications (changelogs).
<type>(<portée>): <description courte>
[corps du message optionnel]
[pied de page optionnel]
Les types acceptés incluent :
- feat : Ajout d'une nouvelle fonctionnalité.
- fix : Correction d'un bogue.
- docs : Modifications de la documentation.
- refactor : Réorganisation du code sans changement fonctionnel.
- ci : Mise à jour des scripts de déploiement ou d'intégration.
Critères de validation et Revue de Code
Une Pull Request ne peut être fusionnée que si elle répond aux exigences suivantes :
- Référence à une Issue existante (ex:
Closes #456). - Passage intégral des tests automatisés de la CI.
- Absence de régression sur la couverture de test (cible > 80%).
- Documentation mise à jour si l'interface utilisateur ou l'API change.
Matrice d'évaluation technique
| Axe d'analyse | Points de contrôle |
|---|---|
| Sécurité | Analyse des vecteurs d'attaque potentiels et gestion des secrets. |
| Performance | Utilisation optimale des ressources (CPU/RAM) et efficacité des requêtes. |
| Rétrocompatibilité | Vérification que les changements ne cassent pas les configurations existantes. |
Infrastructure de Qualité (CI/CD)
Le pipeline d'intégration continue d'Authelia exécute une suite exhaustive de tests pour valider chaque commit :
- Tests Unitaires : Exécutés via
go testpour la logique métier. - Tests d'Intégration : Validation des interactions entre modules (LDAP, bases de données, Redis).
- Tests de bout en bout (E2E) : Simulation de parcours utilisateurs réels avec Cypress.
- Analyse Statique : Vérification de la conformité du code (Linting) et détection de vulnérabilités.
En suivant scrupuleusement ces étapes, les contributeurs assurent non seulement la pérennité du projet Authelia, mais bénéficient également d'une montée en compétences sur la gestion de projets open-source d'envergure industrielle.