À l'occasion de la sortie de la version 0.4 de git-bug, je me suis dit que je pourrai te raconter un peu de quoi il retourne. git-bug est un gestionnaire de bugs distribué intégré dans git.
git-bug est un bug tracker distribué intégré dans git, c'est-à-dire que l'ensemble des données des bugs est stocké sous forme d'objet git, sans polluer les branches et fichiers normaux. Mais pour quoi faire ? Et bien par rapport à un bug tracker classique, il y a plusieurs avantages :
- pas de dépendance à un service en particulier (par exemple si ton bugtracker préféré se fait racheter par tousse Microsoft tousse) ;
- pas besoin d'infrastructure particulière : si tu utilises déjà un remote git pour collaborer, tu as un bugtracker ;
- tu peux consulter et éditer les bugs hors-ligne, avec l'interface que tu préfères, sans latence.
Mais alors, comment on fait un bug tracker distribué ? Le plus gros problème c'est la gestion des conflits. Comment faire si Alice et Bob modifient le même bug et s'échangent les données ensuite ?
La solution choisie, plutôt que de stocker simplement l'état d'un bug, est de stocker chaque opération d'édition individuellement.
+-------------+ +-----------+ +-------------+ +--------+
* --->| ADD_COMMENT |--->| SET_TITLE |--->| ADD_COMMENT |-->| CREATE |
+-------------+ +-----------+ +-------------+ +--------+
Quand une fusion doit avoir lieu, l'une des deux versions voit ses nouvelles opérations placées à la fin de la chaine, à la manière d'un rebase. On a donc la garantie d'avoir un état final cohérent puisque c'est git-bug qui dérive l'état final de la chaîne d'opérations. Mais que se passe-t-il si deux personnes suppriment la même étiquette ? Elle sera simplement supprimée une fois et l'action des deux personnes sera visible dans l'historique.
Voilà à quoi pourrait ressembler une opération :
{
"type": "SET_TITLE",
"author": {
"name": "René Descartes",
"email": "rene.descartes@example.com"
},
"timestamp": 1533640589,
"title": "This title is better"
}Ces opérations sont ensuite sérialisées et stockées dans des blob git et reliées dans une chaîne de commits. Chaque bug a sa propre chaîne de commits, accessible via une référence git. À chaque fois que le bug est modifié, une nouvelle série d'opérations est ajoutée à la chaîne et la référence est mise à jour.
refs/bugs/<bug-id>
|
|
v
+-----------+ +-----------+ "ops" +-----------+
| Commit |--->| Tree |---------+----------->| Blob | (OperationPack)
+-----------+ +-----------+ | +-----------+
| |
| |
v | "root" +-----------+
+-----------+ +-----------+ +----------->| Blob | (OperationPack)
| Commit |--->| Tree |-- ... | +-----------+
+-----------+ +-----------+ |
| |
| | "media" +-----------+ +-----------+
v +----------->| Tree |---+--->| Blob | bug.jpg
+-----------+ +-----------+ +-----------+ | +-----------+
| Commit |--->| Tree |-- ... |
+-----------+ +-----------+ | +-----------+
+--->| Blob | demo.mp4
+-----------+
Comme tout est stocké sous forme d'objet git, on peut pousser tout ça vers un remote et collaborer, comme si on s'échangeait du code source.
Une autre propriété intéressante de la méthode, c'est qu'on peut stocker et lier les médias (typiquement, une capture d'écran) à un bug et les diffuser de la même façon.
Alors, à quoi ça ressemble tout ça ? Et bien ça dépend des goûts. Si tu préfères la ligne de commande, le scripting ou intégrer ça dans ton Vim, c'est possible. Voilà un aperçu:
# Ajouter un nouveau bug
git bug add
# Liste les bugs ouverts, trié par dernière édition
git bug ls "status:open sort:edit"
# Affiche l'état du bug f3781aee
git bug show f3
# Selectionne le bug f3781aee parce que je sais bien que tu es un peu flemmard
git bug select f3
# Ajoute un nouveau commentaire
git bug comment add
# Pousse les modifications vers le remote par défaut
git bug pushPour un usage plus efficace, il y a aussi l'interface interactive en terminal :
Ou sinon, pour les amateurs de vrai pixels et de clic-clic, git-bug embarque une interface web, mais il faut avouer qu'il y a encore du boulot :
Techniquement, le binaire de git-bug lance un serveur web local qui sert les fichiers d'une application REACT (JavaScript) qui ont été compilés et inclus dans ce même binaire. L'application web s'interface avec le binaire grâce à une API GraphQL. Le déploiement reste donc extrêmement simple avec un unique binaire à copier, sans configuration.
La nouvelle version 0.4 apporte une fonctionalité qui a été beaucoup demandée, un importeur incrémental pour Github ! Après avoir utilisé git bug bridge configure pour saisir ses identifiants, un token d'API est généré automatiquement et git-bug devient capable d'aspirer les issues en local dans son modèle de données.
Et le futur ? Une de mes priorités est d'implémenter un exporteur vers Github. Quand ça sera fait, il sera possible d'utiliser git-bug comme un Github déporté, qui fonctionne en local et offline.
Une autre idée qui me trotte dans la tête est d'avoir une véritable gestion d'identité en embarquant les données publiques dans des objets git, clé de chiffrement incluse. De cette façon, il devient possible de les distribuer facilement, avec les données des bugs, de signer ses éditions, les vérifier, et même pourquoi pas ? de vérifier les commits git normaux sans avoir à chercher et importer les clés GPG.
Mais tout ça, c'est quand même beaucoup pour, en gros, un seul bonhomme. Mais peut-être, mon cher journal, que je trouverai des âmes vaillantes pour m'accompagner dans cette aventure…
Aller plus loin
- Journal à l'origine de la dépêche (166 clics)
- Le projet git-bug (611 clics)
- Téléchargement et versions (134 clics)
# La taille ça compte...
Posté par Flyounet (site web personnel) . Évalué à 5.
J'aime bien l'idée.
Quelle est l'espace utilisé par une centaine de bugs avec quelques images (disons une vingtaine) ?
Admettons que j'ai deux repositories dans lesquels je push. Des utilisateurs différents sur chaque remote.
Les bugs vont-ils être mergés ou font-ils parti de "namespace" différents ?
[^] # Re: La taille ça compte...
Posté par MichaelMure (site web personnel) . Évalué à 9. Dernière modification le 06 décembre 2018 à 13:08.
J'ai fais un test avec 10.000 bugs, 10 commentaires par bug (du vrai texte représentatif d'une discussion) et le résultat est de 21Mo après un
git gcqui compresse les données. Bien sûr, si tu ajoute des images, ça fera gonfler la facture, de la même façon que dans un commit normal.Cela dit, chaque bug est indépendant, donc il est possible de récupérer qu'une copie partielle d'un dépôt, comme par exemple ignorer des bugs marqué comme "archivé", récupérer uniquement les bugs récents ou ceux où on participe à la discussion.
Si un bug est créer et poussé vers 2 dépôts différents, il a toujours le même identifiants et pourra être fusionné ultérieurement, même si il y a eu des changements des deux cotés. Bien sûr, même si il y aura toujours un état final "légal", l'historique sera probablement différent ce que tu attend. Dans un système distribué, tu ne peux pas te baser sur des dates/horaires pour déterminer l'ordre des évènements, donc il n'est pas possible d'entrelacer les opérations de manière fiable pendant la fusion. Dans la pratique, tu voudra probablement éviter ce scénario.
[^] # Re: La taille ça compte...
Posté par Albert_ . Évalué à 2.
Mettre des images dans un repo git c'est … une (tres) mauvaise idee!!!
Pour ca il faut passer par git lfs (qui semble tre devenu la norme pour cela) ou git annexe mais voir point precedent.
[^] # Re: La taille ça compte...
Posté par cosmocat . Évalué à 2. Dernière modification le 07 décembre 2018 à 12:35.
oui, sauf que là, il semble que ce soit
git-bugqui ajoute directement les fichiers dans la "base de données" de git (cfrefs/bugs/<bug-id>).Donc il faut que ce soit
git-bugqui gèregit-lfspour les images.Ce qui doit être plus compliqué à faire…
[^] # Re: La taille ça compte...
Posté par Albert_ . Évalué à 2.
oui je suis d'accord mais cela ne change pas que c'est une extremement mauvaise idee de mettre des fichiers binaires dans un repo git.
Enfin, vous faites ce que vous voulez mais le repo va etre assez rapidement bien pourri et nettoyer ce genre de fichier c'est penible.
[^] # Re: La taille ça compte...
Posté par cosmocat . Évalué à 2.
Ah mais j'étais d'accord ;)
[^] # Re: La taille ça compte...
Posté par MichaelMure (site web personnel) . Évalué à 3.
Du point de vue de l'utilisateur, il n'y a rien a nettoyer ou même à gérer. Les fichiers sont lié aux bugs, téléchargé par git en même temps, et seront nettoyé si le bug n'est plus présent localement.
Alors oui, ça prend de l'espace disque, mais c'est tout à fait possible de ne récupérer qu'une sélection des bugs disponible sur le dépôt distant.
Ajouter des fichiers binaires dans git à une mauvaise réputation, mais c'est surtout parce que git n'est pas capable de les fusionner en cas de conflit et parce qu'ils s'accumulent avec le temps. Mais pour git-but ce n'est respectivement pas et pas nécessairement un problème.
[^] # Re: La taille ça compte...
Posté par cosmocat . Évalué à 2.
Pas seulement, c'est aussi lourd lors du clone (contrairement à lfs qui télécharge que les binaires qui vont populer le répertoire de travail).
Ce qui peut être très pénalisant quand tu dois cloner souvent comme par exemple les serveurs de build.
[^] # Re: La taille ça compte...
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Pour des serveurs de build, ça se contourne facilement en ne clonant que la branche à builder, voir même que les
derniers commits de la branche en question. C'est ce que fait travis par exemple (avec 
). On peut même aller plus loin avec les sparse checkout.
[^] # Re: La taille ça compte...
Posté par Albert_ . Évalué à 3. Dernière modification le 09 décembre 2018 à 21:51.
Le probleme n'est pas trop la place disque. Le vrai probleme des binaires dans git c'est que ca te bousille ton depot… Je te suggere de mettre plein de binaire dans un depot et de tester l'acces a ton depot au fur et a mesure. Tu risques d'etre un peu surpris de l'effet de l'engraissage de ton depot sur sa velocite…
Sans parler de fusion et de conflit, notion meme pas existante dans un binaire vu qu'ils seront par definition meme different et totalement different d'ou la notion de diff totalement inutile dessus. Par contre ca va "bloater" ton deport comme je le dis au dessus.
Pour petite information, Github n'autorise plus les depots de plus de 1 Giga (oui j'ai eu a faire a des depots de cette taille merci le commit de dll dedans qu'il a fallu nettoyer a la mano en re-ecrivant l'historique. Operation que git aime "beaucoup"… oui je suis ironique).
Donc j'insiste et je suis desole mais non mettre des images dans un repos git n'est pas une bonne idee.
# Excellente idée
Posté par Jokernathan . Évalué à 10.
Je trouve l'idée très bonne et (d'après ce que montre la capture) la réalisation plutôt bien foutue notamment l'interface terminal. Et j'adore le logo !
J'espère que tu vas augmenter rapidement ton nombre d'utilisateurs et de contributeurs pour ajouter de nouvelles fonctionnalités. Je pense notamment que tout ce qui est migration et/ou lien vers des systèmes de suivi existant est ce qui va être recherché en premier pour l'adoption de ce type d'outil.
Petite question au passage : le suivi des bugs de git-bug est-il fait avec git-bug ?
[^] # Re: Excellente idée
Posté par MichaelMure (site web personnel) . Évalué à 10.
Le suivi des bugs de git-bug n'est pas fait avec git-bug actuellement, pour plusieurs raisons:
# conflit avec git-extras
Posté par autra . Évalué à 3.
Bravo, c'est une super idée !!
Par contre: petit problème de nom qui fait conflit avec
git-bugougit bugfournit par le paquetgit-extrassous ubuntu, cf https://github.com/tj/git-extrasdu coup, même en l'ayant installé, je ne peux pas l'avoir dans le path tant que je ne désinstalle pas ce paquet. Ya un workaround ? Est-ce qu'un renommage est envisageable ?
[^] # Re: conflit avec git-extras
Posté par MichaelMure (site web personnel) . Évalué à 1.
C'est vrai, il y a un conflit. Je réfléchis à sortir du système de commande git porcelain et à renommer le binaire en
gbpar exemple. Plus de conflit et des commandes plus courte.[^] # Re: conflit avec git-extras
Posté par windu.2b . Évalué à 3.
Et en renommant en
git bt(pour bugtracker) ?[^] # Re: conflit avec git-extras
Posté par MichaelMure (site web personnel) . Évalué à 2.
Ça m’embête un peu de perdre la corrélation entre le nom du projet et la commande :-|
[^] # Re: conflit avec git-extras
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
gbce sera pas top non plus.g btreste court est compréhensible je pense (j'ai un alias de git sur g)[^] # Re: conflit avec git-extras
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Pourquoi pas L, el ou elle alors ?
# Dommage que ce soit git only
Posté par David Demelier (site web personnel) . Évalué à 5.
J'ai toujours aimé l'idée d'avoir un bug tracker directement dans le dépôt. Il y a eu d'autres tentatives comme ditz ou bugseverywhere.
L'interface avait l'air chouette, mais étant utilisateur et contributeur Mercurial j'aurai bien aimé qu'il soit SCM indépendant. Dommage.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dommage que ce soit git only
Posté par MichaelMure (site web personnel) . Évalué à 5. Dernière modification le 06 décembre 2018 à 17:12.
Dans l'absolu, ça serait pas forcement difficile de le porter sur Mercurial. Si c'est possible de faire correspondre les concepts et d'implémenter l'interface qui va bien (https://github.com/MichaelMure/git-bug/blob/master/repository/repo.go), ça devrait marcher.
Mais je connais que vaguement Mercurial, aucune idée si c'est jouable …
# Pourquoi une nouvelle branche?
Posté par freem . Évalué à 4. Dernière modification le 06 décembre 2018 à 22:12.
Ce n'est pas le 1er bugtracker intégré au DVCS sur lequel je tombe, parce que, j'en cherche un depuis longtemps (sans trop me forcer quand même), qui me convienne (mais je suis un grand chieur, donc…).
Je m'aperçois que la plupart se concentrent sur le fait d'isoler la gestion des bugs sur une branche différente, et je me demande pourquoi.
Après tout, un bug peut n'être lié qu'à une branche précise, et tant qu'il n'est pas résolu, il devrait parfois pouvoir bloquer la fusion.
Donc, pourquoi ne pas juste créer une arborescence, avec quelques éventuels scripts (inclus via peu importe quel moyen), pour ça?
C'est justement un des trucs qui font que je trouve fossil pas si intéressant que ça, en plus du fait de nécessiter un outillage binaire spécial rien que pour ça.
[^] # Re: Pourquoi une nouvelle branche?
Posté par MichaelMure (site web personnel) . Évalué à 10.
Plusieurs raisons:
Mais tout ça, ça ne veut pas dire que les bugs ne peuvent pas être "conscient" de la notion de branche. C'est bien plus simple et souple de rajouter ce concept par la suite plutôt que de se lier les mains dans le dos tout de suite.
# Pourquoi que les bugs?
Posté par cosmocat . Évalué à 5.
J'aime beaucoup l'idée depuis que j'avais découvert le plus maintenu http://www.bugseverywhere.org/
La question que je me pose, c'est pourquoi s'être restreint aux bugs, qui ne sont en fait qu'un cas particulier de tâches.
Comme ça, on pourrait gérer des taches et mettre ça sur un board…
J'avais découvert çà également, qui est pas mal sur le principe mais le format est mal fichu et, même s'il peut être commité, ne facilite pas le travail a plusieurs (et les merges)
https://marketplace.visualstudio.com/items?itemName=mkloubert.vscode-kanban
[^] # Re: Pourquoi que les bugs?
Posté par MichaelMure (site web personnel) . Évalué à 2.
Le projet est limité au bug simplement parce que son équipe de développement est composé d'une personne, qui a un boulot à plein temps maintenant. Mais ça serait très chouette d'appliquer la même technique à d'autres domaines.
# Génération du token
Posté par Steap . Évalué à 1.
Puis-je récupérer les bugs anonymement ? Puis-je fournir mon propre token plutôt que de taper mes identifiants ? Comment met-on à jour la liste des bugs (y a-t-il une commande similaire à "git fetch" ?) ?
[^] # Re: Génération du token
Posté par MichaelMure (site web personnel) . Évalué à 1.
Pour le pire ou le meilleur, j'ai choisi d'utiliser l'api V4 (graphql) de Github qui impose une authentification. Donc non actuellement.
Actuellement non, mais ça serait une bonne chose à avoir, par exemple avec un flag pour la commande
git bug bridge configure. Mais ça demande d'avoir une bonne documentation pour expliquer comment générer le token et avec quelles options.git bug pull# Modération ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
C'est intéressant, j'aime particulièrement l'interface ncurses :)
Est-ce qu'il est prévu de pouvoir modérer les tickets sur le repo central avant qu'ils soient ajoutés à la base qui sera clonée / syncée par les clones ? Comme dans Fossil en fait.
Idem est-ce qu'il est possible d'avoir des notifications par email ?
Et enfin est-ce que l'API est accessible en HTTP à partir d'un autre serveur / client ? Notamment je pense à la possibilité de créer un bug à partir d'un rapport d'erreur dans Sentry / etc.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Modération ?
Posté par MichaelMure (site web personnel) . Évalué à 2.
C'est pas quelque chose que j'avais imaginé, mais je t'encourage à ouvrir un ticket pour démarrer une discussion et voir si ça trouve son public.
Difficile de faire ça avec juste une commande git. Mais le plan à long terme c'est de voir l'interface web évoluer en un portail public central qu'un projet pourrait héberger pour remplacer entièrement Github et autre. A ce moment là, ça devient possible d'envoyer des mails facilement.
L'API GraphQL est uniquement accessible sur 127.0.0.1 actuellement, mais ça serait pas très compliqué d'ajouter une configuration pour ça. Où même d'ajouter une API REST minimaliste si GraphQL pose problème.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.