Merci de contribuer à la Console Cloud Pi Native. Ce guide s'applique aux contributions quelles qu'elles soient, qu'elles concernent du code, de la configuration, des dépendances ou de la documentation.
La Console fournit une interface unifiée pour piloter les services de l'offre Cloud Pi Native, automatiser le cycle de vie des projets et appliquer les exigences DevSecOps de sécurité, de qualité, de maintenabilité et d'interopérabilité.
Toute évolution doit démontrer son alignement avec cette vision avant toute implémentation. Une contribution qui ne sert pas l'offre, son architecture ou sa feuille de route ne peut pas être acceptée.
Toute contribution de code doit être adossée à un ticket. Ce ticket décrit :
- Le besoin traité et son alignement avec la vision produit ou la feuille de route ;
- Le périmètre fonctionnel et technique de la contribution ;
- Les critères d'acceptation ;
- Les impacts connus sur la sécurité, les contrats API, les données, l'exploitation et la documentation.
Les modèles de ticket GitHub sont à utiliser afin de nous aider à correctement catégoriser les demandes.
Pour une contribution de code qui corrige un bug, une procédure de reproduction, un test automatisé de non-régression et, pour une interface, des captures d'écran sont fortement recommandés lorsqu'ils sont pertinents. Leur absence ne bloque pas la contribution lorsqu'ils ne peuvent pas s'appliquer.
Pour une contribution de code qui permet de rajouter une nouvelle fonctionnalité, joindre des maquettes ou croquis, même rudimentaires, est encouragé.
Les contributions strictement documentaires ou typographiques, sans impact fonctionnel, sont les seules contributions qui ne nécessitent pas de ticket. Elles restent soumises au contrôle de périmètre et aux exigences de qualité adaptées.
Une pull request ou merge request ne contient que les changements nécessaires au sujet décrit par son ticket. Les commits, fichiers ou changements sans rapport direct avec ce sujet sont rejetés et doivent être proposés séparément, avec leur propre ticket.
Utilisez le template de pull request pour présenter le comportement modifié et les informations utiles à la revue. Son évolution est traitée séparément de ce guide.
Une approbation explicite de l'équipe Co est obligatoire pour toute contribution de code qui n'est ni une correction de bug ni un changement trivial.
L'approbation explicite de l'équipe CPIN est obligatoire dans tous les cas pour :
- l'ajout, la suppression ou la mise à niveau d'une dépendance Node.js ;
- l'ajout ou la mise à niveau d'un outil installé dans une image Docker ;
- tout autre changement de dépendance ayant un impact sur la chaîne d'approvisionnement, la sécurité ou la maintenance.
Les corrections de bugs et les changements triviaux ne dispensent ni du contrôle de périmètre, ni de la revue de code, ni des contrôles qualité. Une dépendance ajoutée pour corriger un bug doit donc recevoir l'approbation explicite de l'équipe CPIN.
apps/server est le backend historique et ne reçoit plus de contribution.
Toute pull request ou merge request qui modifie ce dossier est rejetée, y
compris pour une correction de bug.
Les évolutions backend ciblent exclusivement apps/server-nestjs. Elles
suivent le plan de modularisation backend vers NestJS, l'état de migration, les conventions NestJS et la stratégie de tests associée. Toute dérogation est une décision explicite de l'équipe CPIN, hors du flux normal de contribution.
Respectez les frontières et conventions de la zone modifiée :
- le frontend Vue 3 et le système de design existant ;
- les modules NestJS et Prisma dans
apps/server-nestjspour le backend ; - les contrats partagés, permissions et schémas de données ;
- les plugins et leurs mécanismes de cycle de vie lorsqu'ils sont concernés.
Ajoutez ou adaptez les tests proportionnés au risque et au périmètre : tests unitaires ou d'intégration pour la logique et les contrats, et tests Playwright pour les parcours utilisateurs affectés. Mettez à jour la documentation lorsqu'un comportement, une API, une configuration, une opération ou une migration est affectée.
Avant soumission, exécutez les contrôles adaptés à votre modification :
pnpm lint
pnpm test
pnpm playwright:testLe test Playwright est requis lorsque la contribution affecte un parcours
utilisateur. Respectez aussi TypeScript strict, ESLint, Stylelint pour le
client, les hooks Husky et la CI. Les messages de commit suivent Conventional
Commits et sont rédigés en anglais. Rebasez votre branche sur origin/main
avant la demande de fusion.
Consultez et citez les références appropriées dans le ticket :
- La documentation publique Cloud Pi Native, notamment l'introduction de la plateforme et la feuille de route ;
- L'architecture et les conventions du dépôt ;
- Le plan de modularisation NestJS ;
La feuille de route publique est actuellement en cours de rédaction. Son indisponibilité ne bloque pas la qualification : le ticket doit alors exposer une justification concise au regard de la vision produit.