merge-matrix  •  Détectez les conflits à l’avance

Évitez les surprises au dernier moment

a marqué ce sujet comme résolu.
Auteur du sujet

Hello,

Depuis quelque temps, j’ai un petit service rigolo qui tourne sur mon VPS.

Si vous ne savez pas ce qu’est un gestionnaire de version, ne perdez pas votre temps à lire la suite, cela ne vous intéressera probablement pas.

De façon à ce que vous ayez une idée claire de la chose, je pense qu’il est pertinent de commencer par résumer la naissance de ce projet. Revenons-donc un mois en arrière.

Il y a donc environ un mois, j’étais en train de m’amuser à contribuer au développement de ZdS, et on avait des petits problèmes de PRs (Pull Request, des propositions de patch dans le jargon de GitHub). C’était une période où on pouvait ouvrir et fermer pas mal de PRs en une journée, et certaines d’entre elles pouvaient être très grosses comme celle de la réécriture de l’implémentation du zmarkdown.

On arrive vite à un moment où tout le monde ne peut pas suivre ce que fait tout le monde, et se retrouve vite face à des problèmes de conflits assez traîtres.

Voici un petit scénario qui m’est arrivé : J’avais fais une PR retirant une balise <div> du gros template de base du site qui englobait tout le menu principal. Du coup, j’avais réindenté tout le contenu de cette balise, en retirant quatre espaces au début de chaque ligne. Ça faisait plusieurs centaines de lignes de modifiées. Pendant ce temps, victor, travaillant sur la PR de zmarkdown, avait modifié aussi (plus légèrement) le même fichier. Jusqu’à ce moment, personne ne s’est rendu compte que ces PRs modifiant les mêmes lignes du code ne peuvent pas être mergée sans résoudre manuellement le conflit. Et ma PR a été mergée en premier : Paf, on ne peut plus merger celle de zmarkdown alors que cette dernière était la plus urgente !

Bon, j’ai résolu ces conflits (un peu à l’arrache) sans trop tarder, mais qu’est-ce qui se serait passé si je m’étais absenté pendant une semaine ? Ça aurait stressé toute l’équipe pour pas grand-chose, et des gens auraient corrigé des conflits dans du code qu’ils ne connaissent pas forcément très bien (c’est une très bonne manière d’introduire des bugs).

Du coup, suite à une petite discussion avec victor sur IRC, cette idée de détecter les conflits entre les PRs à l’avance a murie un peu dans ma tête, et j’ai donc écrit un petit prototype vite fait. Le principe est simple : On a un cron qui, toutes les 5 minutes, essaye de merger toutes les PRs entre elles. Les résultats de chaque git merge sont archivés, et on construit une belle matrice où les cases blanches veulent dire “pas de conflit”, et les cases roses ou rouges veulent dire “conflit”. Le numéro dans ces dernières indique le nombre de lignes entrant en conflit.

Quand on clique sur une case, on accède à un détail du git merge.

Notez qu’il y a des numéros de commit dans l’URL, et non des noms de branche : C’est parce que les branches sont muables, alors que les commits ne le sont pas. Alors que la matrice est mise-à-jour fréquemment, chaque résultat de merge est archivé et jamais supprimé.

Sur la même page, vous pouvez voir un détail des fichiers entrant en conflit pour chaque git merge ayant échoué.


Qu’en pensez vous ? Je vous présente ça vu que des gens sur IRC trouvent ça cool. J’attends vos suggestions, vos critiques et vos questions. On m’as parlé d’idées de dingue comme faire une vraie intégration à GitHub (et pourquoi pas GitLab et Gogs), mais j’ai d’abord envie d’être certain que ce projet a un intérêt avant de faire quelque chose de plus compliqué que ce prototype.

Et évidemment, c’est open-source.

Voilà, c’était un peu long, désolé :)

Édité par motet-a

+22 -0

Salut,

Franchement bon projet ! Je pense qu’on est plus d’un à avoir été dans une situation aussi galère à gérer :lol:

Je garde ça dans un coin lors d’un éventuel prochain travail d’équipe, merci.

Si tu as un peu de temps, n’hésite pas à faire un p’tit tour pour voir mon projet ZONNY

+3 -0

C’est top.

Ca fonctionnerait en tant que plugin gitlab ?


EDIT :

Oups, c’était marqué à la fin de ton message. Du coup bah "+1" pour l’intégration Gitlab.

Édité par Javier

Happiness is a warm puppy

+3 -0
Auteur du sujet

D’ailleurs, on pourrait peut-être analyser la matrice de façon à faire un classement automatique des PRs en fonction de leur dangerosité : En général, celles dont il faut se méfier sont celles qui mergent dans master mais pas ailleurs. Mais je ne sais pas si ça serait très fiable.

(J’ai un peu foiré un déploiement tout à l’heure, c’était en panne entre 12h et 13h si par hazard vous êtes l’une des deux personnes qui se sont tapés une 502 selon mes logs).

+0 -0
Auteur du sujet

Au fait, il y a des gens qui sont intéressés pour déployer ça avec Docker ? Ou vous pensez plutôt déployer ça sans Docker ? Ou vous avez la fleimme de déployer un truc comme ça vous-même ?

(Et n’hésitez pas à dire que vous avez la fleimme hein, je le comprends tout à fait)

+0 -0
Auteur du sujet

Bon, je déterre avec pleins de nouvelles :)

J’ai converti mon image Docker à l’arrache en un automated build, ça me semble beaucoup mieux niveau sécurité. J’ai changé l’URL pour que ça corresponde avec le slug du dépot, maintenant c’est moteta/merge-matrix.

Il y a quelques jours, quelqu’un m’a redemandé si ça marcherait avec GitLab. J’ai vraiment l’impression que ce truc pourrait être utile à pas mal de monde, et actuellement ça ne marche pas si bien quand on a beaucoup de PRs à cause de certains problèmes de conception. Genre avec les 40 PRs du dépot de ZdS, c’est assez limite. J’hésite vraiment à réécrire tout ce prototype un peu sale au “propre”, éventuellement avec Elixir parce que je m’y intéresse pas mal et parce que ça me semble assez adapté pour ce genre de chose.

Autre chose, pour corriger les récents problèmes que j’ai rencontré en production avec ce truc, je pense qu’utiliser une base de données est le bon choix à faire. Je pense plutôt partir sur SQLite (surtout parce que c’est vraiment embarquable dans l’application, sans rajouter tout un pénible travail de sysadmin).

J’attends vos commentaires :)

Édité par motet-a

+4 -0

Je re +1 pour l’intégration Gitlab, c’est là où ça aurait le plus de valeur ajoutée pour mon petit cas perso à moi.

J’hésite vraiment à réécrire tout ce prototype

Y’a jamais à hésiter. C’est ton projet, c’est du perso, t’as 100% de marge de manoeuvre. C’est un luxe que tu peux te payer, vas-y.

éventuellement avec Elixir parce que je m’y intéresse pas mal

Raison de plus pour le ré-écrire.

ça me semble assez adapté pour ce genre de chose.

Sans doute pas plus que d’autres trucs mais si t’as envie d’essayer trace.

La seule question à te poser c’est :

  • en faire un plugin Gitlab
  • ré-écrire en Elixir

C’est compatible ?

Si oui, bah vas-y.

Si non, malheureusement arbitre entre les deux et priorise ce que tu préfères.

J’espère pouvoir t’aider pour l’un comme pour l’autre. Pas de promesse mais je continue à suivre ton repo.

Happiness is a warm puppy

+0 -0
Auteur du sujet

La seule question à te poser c’est :

  • en faire un plugin Gitlab
  • ré-écrire en Elixir

C’est compatible ?

Bah, Elixir a un écosystème qui commence à devenir un peu conséquent, même si ce n’est pas du tout aussi énorme que le monde de Python ou Node.js, je pense qu’on peut dire que c’est à peu près compatible avec tout (si ça répond à ta question).

Concernant l’intégration avec GitLab, je pensait surtout me servir de l’API exactement comme ce que je fais actuellement avec GitHub. Après, merge-matrix pourrait très bien exposer sa propre API pour faire des choses plus poussées :)

Ça te convient ?

+0 -0

Ah pardon j’avais pas compris. Ton appli est standalone et se connecterait à Gitlab.

Je pensais que tu voulais développer un plugin qu’on pouvait installer directement sur Gitlab pour visualiser la matrice dans une discussion attachée à une merge request par exemple.

Happiness is a warm puppy

+0 -0

Ouais, exactement. Après on peut parfaitement envisager de faire un bot qui poste des messages sur les merge requests, comme ce qu’il se fait couramment sur GitHub.

motet-a

Me semble que les APIs pour ça sont de bêtes webhooks, pour gitlab et pour github. Du coup ça devrait pas poser un gros problème, quel que soit le langage, ouais :)

+1 -0

As-tu pensé à un système de notifications ? Cela serait bien (d’après moi) d’être prévenu automatiquement des conflits. Au moins ça évite d’avoir à actualiser toutes les 5 minutes la page :p Juste un truc basique du style notifications web. Après y’a peut-être mieux comme moyen de notifier…

Si tu as un peu de temps, n’hésite pas à faire un p’tit tour pour voir mon projet ZONNY

+0 -0
Auteur du sujet

Juste un truc basique du style notifications web.

Ça c’est juste du frontend. Derrière, pour que ça marche, il faud du long-polling, des WebSockets ou quelque chose du genre mais oui, c’est possible.

En fait je pense que je ne vais pas trop m’intéresser au frontend pour l’instant et que je vais commencer par faire en sorte que le backend soit solide et stable.

(Pour moi, tout ce qui est du genre “commentaires sur les PRs”, “notifications” et “UI” ça compte tout pour du frontend hein)

Édité par motet-a

+4 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte