Feuille de route : rien de ceci n'existe encore

Un scan de code n'a de sens que si la plateforme comprend les vérifications : des résultats qui appartiennent à un commit, s'affichent sur une demande de fusion et peuvent en bloquer la fusion. Cette version construit ce socle, traduit l'interface et laisse choisir son thème.

• Branches protégées : pas de push direct, fusion uniquement par une demande de fusion, approbations et vérifications obligatoires.
• Pipelines sur les demandes de fusion, avec leur statut affiché sur la demande et exigé avant la fusion.
• Variables CI prédéfinies (commit, branche, demande de fusion, pipeline) et rules pour décider quand un job s'exécute.
• Artefacts de pipeline et API d'envoi de rapports, dont se serviront les scans des versions suivantes.
• Relance d'un pipeline depuis l'interface, et pipelines planifiés.
• Jetons d'accès personnels utilisables sur l'API REST, avec des portées, et une description OpenAPI générée depuis le code.
• Un premier lien avec ArtiFerris : publier vers une instance ArtiFerris un artefact construit par un pipeline.
• L'interface en anglais, français, italien, espagnol et allemand. La langue suit le navigateur à la première visite, peut être changée à la volée et est enregistrée sur le compte. Les e-mails envoyés par FerrisGit utilisent la langue du destinataire, et les pages publiques suivent l'Accept-Language du lecteur. La documentation est traduite ensuite.
• Le mode sombre comme réglage : système, clair ou sombre, enregistré sur le compte et appliqué sans clignotement. L'interface suit aujourd'hui le réglage du système, sans bouton. Le logo du shell connecté suit aussi le thème.

FerrisGit se dote de son propre moteur d'analyse plutôt que d'envelopper des outils tiers : un binaire ferrisgit-scan lancé par un job de pipeline, de sorte que l'analyse s'étend avec les runners et que le serveur reste léger. Ses analyseurs sont des plugins qui produisent des constats dans un modèle proche de SARIF, si bien que les rapports d'autres outils peuvent être importés à côté des constats natifs.

• Le moteur et le stockage des constats : un scan par commit, des constats identifiés par une empreinte stable, et une référence par branche pour distinguer les nouveaux constats d'une demande de fusion des anciens.
• Détection native des secrets, dans le diff d'une demande de fusion et dans tout l'historique.
• Audit natif des dépendances : fichiers de verrouillage (Cargo.lock, package-lock.json, d'autres plus tard) comparés à des bases d'avis publiques comme OSV.
• Constats affichés en ligne dans le diff de la demande de fusion et résumés dans sa chronologie.
• Import de rapports SARIF d'autres outils.

• Portes qualité, configurables par dépôt : par exemple aucun nouveau constat bloquant et une couverture minimale sur le code nouveau. Une porte est une vérification obligatoire : elle peut donc bloquer une fusion.
• Un tableau de bord par dépôt : constats ouverts, leur ancienneté, tendance par branche, dette technique et points chauds.
• Tri des constats : marquer un constat comme faux positif ou comme à ne pas corriger, l'assigner, le supprimer dans le code, et conserver l'historique.
• Un fichier .ferrisgit/scan.yml pour choisir les analyseurs, les jeux de règles et les seuils, et pour exclure des chemins.

Tout le dépôt est analysé à chaque push sur la branche par défaut et à chaque demande de fusion, et les portes ne regardent que ce qu'une demande de fusion introduit (l'approche « clean as you code »), si bien qu'un projet existant reste adoptable.

• Analyse syntaxique avec tree-sitter, pour que le même moteur lise plusieurs langages. Rust et TypeScript d'abord.
• Métriques : taille, complexité cyclomatique et cognitive, duplication.
• Mauvaises pratiques et motifs de bugs, sous forme de règles déclaratives et de règles natives.
• Suivi de la couverture de tests (rapports LCOV et Cobertura), avec la couverture de ce que modifie une demande de fusion.

• Test statique de sécurité des applications : des règles de motifs d'abord, puis le flux de données à l'intérieur d'une fonction.
• Analyse des images de conteneurs et de l'infrastructure décrite en code.
• Un résumé de sécurité sur chaque demande de fusion et un tableau de bord de sécurité par dépôt, avec des sévérités et la possibilité de bloquer la fusion au-dessus d'une sévérité choisie.
• Retracer chaque artefact publié vers ArtiFerris jusqu'au commit, à la demande de fusion et au pipeline qui l'ont produit, et l'afficher sur les pages de release et de pipeline de FerrisGit.
• Ramener les résultats d'analyse des artefacts d'ArtiFerris dans les vérifications des demandes de fusion.
• Étudier une identité partagée, pour qu'un seul compte et une seule inscription MFA fonctionnent sur les deux plateformes.

• Git en SSH et clés de déploiement.
• Forks et demandes de fusion entre dépôts ; renommage et transfert d'un dépôt avec redirections.
• Fusions squash et rebase, réouverture d'une demande de fusion, demandes de fusion en brouillon et CODEOWNERS.
• Mentions (@nom), références de tickets (#12) et fermeture d'un ticket depuis un commit ou une demande de fusion.
• Recherche plein texte dans le code, et import depuis GitHub et GitLab.
• Réinitialisation du mot de passe en libre-service, notifications par e-mail avec réglages par utilisateur, et authentification unique (OIDC, LDAP).
• Une page de journal d'audit dans l'administration, des métriques Prometheus, et des outils de sauvegarde et de restauration.
• Des webhooks avec nouvelles tentatives, un journal des envois et davantage d'événements (push, release).

Des idées dont le contenu reste à définir.

• Des agents d'IA sur un dépôt. Pistes : un assistant de relecture des demandes de fusion, des résumés de demandes de fusion et de commits, l'explication d'un pipeline en échec, le tri et l'étiquetage des tickets. Pour une plateforme auto-hébergée, ils utiliseraient un modèle choisi par l'administrateur (un modèle local compris), activé dépôt par dépôt, avec des identifiants limités et chaque action enregistrée.
• Un graphe des commits dans la vue d'un dépôt : branches, fusions et tags dessinés ensemble, à côté de l'arborescence et de la liste des commits qui existent déjà.
• Des photos de profil, stockées sur un espace compatible S3. Les initiales restent en solution de repli, et le même stockage pourrait accueillir plus tard les fichiers de releases et les artefacts de pipeline.

ArtiFerris stocke déjà des paquets npm et des images Docker/OCI et les analyse à la recherche de vulnérabilités. FerrisGit et ArtiFerris sont deux moitiés complémentaires d'une même chaîne de livraison. Le lien se construit en trois étapes : publier depuis un pipeline (0.2), retracer un artefact jusqu'à son commit (0.6), et ramener les résultats d'analyse dans les vérifications des demandes de fusion (0.6). L'identité partagée reste une question ouverte.