GitRoot

 (gitroot.dev)
2 points par GN⁺ 1 일 전 | 1 commentaires | Partager sur WhatsApp
  • GitRoot est une petite forge Git qui gère les dépôts et les droits d’accès dans un binaire unique, et compose des fonctionnalités comme les issues, les tableaux, la fusion de branches et l’interface web via des plugins autonomes
  • Au-delà du code, toutes les données, y compris les issues, les demandes de fusion et les tableaux, sont stockées dans Git sous forme de fichiers ordinaires, sans dépendre d’une base de données séparée ni de blobs cachés
  • Les modifications sont contrôlées via .gitroot/users.yml et des droits d’écriture par branche ; seuls les utilisateurs autorisés peuvent pousser vers la branche par défaut, qui représente l’état actuel du dépôt
  • Le projet est actuellement en version alpha : il prend en charge les dépôts, les utilisateurs, les plugins, les commandes Git en SSH et la consultation en HTTP, mais n’est pas adapté à un usage en production
  • D’ici la version 1.0, le projet prévoit des mises à jour, des droits au niveau fichier, les commandes Git en HTTP, les groupes et sous-groupes, ainsi que la stabilisation de l’API des plugins ; contribuer aujourd’hui demande de comprendre Git et le fonctionnement du plugin grafter

Une petite forge Git à composer selon ses besoins

  • GitRoot est une petite forge Git qui s’exécute dans un seul binaire et limite ses fonctions de base à la création de dépôts et à la gestion des droits d’accès par dépôt
  • Toutes les autres fonctions sont assurées par des plugins pouvant être installés indépendamment les uns des autres
    • Création d’issues, de roadmaps, de sprints et de jalons
    • Affichage des éléments sous forme de tableau
    • Revue et fusion de branches, appelées graft dans GitRoot
    • Mise à disposition des données du dépôt et de plusieurs fonctions via une interface web
  • Les plugins étant complètement séparés, il est possible d’utiliser uniquement le tableau sans interface web, et de créer soi-même des plugins selon les besoins du projet

Une conception pensée pour adapter la forge à chaque projet

  • Le projet part du principe que chaque équipe a sa propre manière de travailler, et est conçu pour que chaque projet ait la liberté de modifier sa propre forge
  • L’environnement souhaité par le développeur est le suivant
    • Conserver le code, les issues, les pull/merge requests et les tableaux dans un seul dépôt
    • Fournir les fonctions nécessaires à la promotion et à l’exploitation du projet, comme une page d’accueil, des traductions, un système de tickets ou un forum
    • Migrer vers une forge hébergée sur un autre serveur sans scripts de migration ni perte de données ou de traces des contributeurs
  • À l’inverse, il cherche à éviter les complexités suivantes
    • Devoir ouvrir un navigateur pour gérer les pull/merge requests ou les issues
    • Une organisation qui montre d’abord une liste de fichiers et de répertoires à quelqu’un qui découvre le projet
    • Une forge qui impose le sens et le flux de travail des sprints, jalons, epics et user stories
    • Une structure obligeant à parcourir plusieurs menus pour régler un seul droit utilisateur

Autonomie d’installation et d’exploitation

  • Le projet vise un déploiement sans dépendances ni base de données afin que les administrateurs puissent l’installer et le maintenir facilement
  • Les administrateurs doivent pouvoir définir les actions autorisées par utilisateur, et les utilisateurs doivent pouvoir demander eux-mêmes la création et l’accès aux projets et aux fonctions, sans passer par l’e-mail ou le chat
  • L’objectif est de réduire la charge des mises à niveau tout en évitant de confier les données des projets et des utilisateurs à des tiers, ainsi que de dépendre de grands acteurs pouvant modifier brutalement leur politique d’exploitation
  • Le projet n’est pas encore terminé et accepte des contributions externes

Des droits gérés avec des fichiers ordinaires et des branches

  • Au lieu d’une base de données ou de blobs cachés dans l’arborescence Git, toutes les données sont stockées dans des fichiers ordinaires à côté du code
  • Le fichier .gitroot/users.yml de chaque dépôt définit les emplacements où chaque utilisateur peut écrire, et le contrôle d’accès repose principalement sur des restrictions par branche
    • Au départ, seul le propriétaire peut accéder à la branche par défaut
    • Si un utilisateur non autorisé pousse vers la branche par défaut, GitRoot rejette la modification
    • Tout le monde peut créer une nouvelle branche ; l’utilisateur qui la crée obtient le droit d’écriture sur cette branche, et les autres ne peuvent pas la modifier
    • Si .gitroot/users.yml est modifié ou si une branche sur laquelle un utilisateur s’est ajouté est fusionnée, cet utilisateur peut alors pousser vers la branche par défaut
  • Tout le monde peut lire les fichiers et les modifier en local ou sur une nouvelle branche, mais pour répercuter les changements sur la branche par défaut, qui représente l’état actuel du dépôt, une fusion par le propriétaire est nécessaire
  • La configuration de la forge elle-même est aussi gérée dans le dépôt racine
    • Un dépôt est créé lorsqu’une modification est ajoutée à .gitroot/repositories.yml sur la branche par défaut du dépôt racine, ou lorsque cette modification est fusionnée
    • Le fonctionnement détaillé est décrit dans la documentation

Fonctions prises en charge dans la version alpha

  • Le projet est actuellement en version alpha : il peut être testé, mais ne doit pas être utilisé en production
  • Le périmètre pris en charge est le suivant
    • Création et suppression de dépôts
    • Traitement des commandes Git via SSH
    • Gestion, par utilisateur, des emplacements d’écriture au niveau du dépôt et de la branche
    • Installation des plugins et activation par dépôt
    • Exécution des plugins depuis l’arbre de travail lors de l’installation
    • Après l’installation, exécution des plugins sur le diff à chaque commit
    • Consultation des dépôts via HTTP

Feuille de route jusqu’à la version 1.0

  • Le projet prévoit d’implémenter les fonctions suivantes avant la version 1.0
    • Mises à jour de GitRoot et des plugins
    • Gestion des droits utilisateur au niveau fichier
    • Traitement des commandes Git via HTTP
    • Gestion des dépôts avec des groupes et sous-groupes
    • Stabilisation de l’API des plugins

Auto-hébergement et procédure de contribution

  • Le site web de GitRoot est une instance GitRoot qui héberge le code de GitRoot lui-même et fonctionne uniquement pour le projet GitRoot
  • Pour l’essayer sur d’autres projets, il faut suivre la documentation d’installation et d’utilisation
  • GitRoot étant lui-même un dépôt GitRoot, il est possible d’y contribuer de la même manière ; la procédure est expliquée dans le guide de contribution
  • L’instance actuelle utilise le plugin grafter, qui intègre une partie du code dans la branche par défaut ; il faut donc comprendre son fonctionnement avant de contribuer
  • Comme toutes les données, y compris le code, les issues et les traductions, sont stockées dans Git, il faut actuellement savoir utiliser Git pour contribuer
  • À terme, l’objectif est de permettre à tout le monde de participer en exécutant directement git commit et git push depuis le navigateur

À lire aussi

1 commentaires

 
GN⁺ 1 일 전
Avis sur Lobste.rs
  • GitHub n’était pas seulement la plus grande forge Git, mais aussi la plus influente, et son empreinte se ressent dans la conception de Forgejo comme de GitLab. Le déclin de GitHub pourrait favoriser l’apparition de diverses forges s’éloignant du modèle existant, ce qui laisse entrevoir une grande marge d’innovation
    • Gitea a autrefois reproduit presque à l’identique le frontend de GitHub, et Forgejo en a hérité tel quel en forkant Gitea
  • Je suis la personne qui a créé GitRoot ; si vous avez des questions, n’hésitez pas à les poser
    • Trois points m’intriguent. Je me demande pourquoi le CSS a été commité sous forme minifiée : https://gitroot.dev/worktree/app/…
      La limitation de la largeur de la balise <pre> à 720 px semble venir du display:grid sur body ; en le désactivant, elle s’élargit comme prévu. Par ailleurs, l’URL ne contient pas d’information sur le commit précis, ce qui rend difficile pour la personne qui envoie le lien et celle qui le reçoit de voir le même écran. Je comprends que ce soit un projet destiné à des besoins personnels, mais je voulais le signaler comme un point à examiner
  • @manland, je me demande s’il existe une politique ou des directives autorisant ou interdisant les contributions créées avec des LLM
    • Pour l’instant, il n’y a pas de politique particulière. C’est parce qu’en dehors de deux contributeurs ponctuels, j’ai écrit 99,999 % du code moi-même
      Personnellement, je n’utilise pas de LLM pour coder et j’y suis opposé, mais si un patch est suffisamment petit, même s’il a été fait avec un LLM, je ne suis pas certain que je le refuserais
      Comme l’anglais n’est pas ma langue maternelle, j’ai du mal à expliquer GitRoot, donc il y a des traces de LLM dans ma communication externe. J’avais déjà demandé de l’aide sur https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 et https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52, mais personne n’est venu
      Le fait de devoir utiliser des LLM me fait mal, mais plutôt que de ne rien faire, j’ai décidé de les utiliser au minimum. Si une communauté se forme à l’avenir, j’aimerais les exclure complètement ; avant cela, ils pourraient aussi disparaître naturellement pour des raisons économiques. J’ai beaucoup d’articles à écrire dans ma liste de tâches pour expliquer la philosophie, la sécurité et l’avenir du projet, mais l’idée que, au bout du compte, un LLM corrigera mes phrases, mes fautes de frappe ou traduira le texte me fait hésiter à les rédiger
  • J’aime bien le fait d’avoir utilisé TinyGo pour compiler les plugins Go en WASM