Comment nous avons réduit de 94 % la taille git de notre monorepo JavaScript

• 1JS, le vaste monorepo JavaScript de Microsoft, contient une très grande quantité de code et de contributions. Un clone récent du dépôt atteignait 178 Go.
• La taille du dépôt était devenue si importante que certains utilisateurs en Europe ne pouvaient plus le cloner.

Leçon n°1

• Quand l’auteur a rejoint le dépôt il y a quelques années, il a constaté que sa taille augmentait rapidement. Lors de son premier clone, il faisait 1 à 2 Go, mais quelques mois plus tard il avait déjà atteint 4 Go.
• L’outil git-sizer a été utilisé pour repérer les gros blobs, généralement causés par des binaires ajoutés par erreur. La fonctionnalité de limitation de taille des check-ins d’Azure DevOps permet d’éviter cela.
• Le problème venait aussi du fait que les fichiers de changements Beachball n’étaient pas supprimés. Comme Changesets, ils servent à incrémenter automatiquement la plage semver des packages.
• Une autre leçon a été de ne pas conserver des milliers de fichiers dans un seul dossier. Pour corriger cela, une pull request a été soumise à Beachball afin de regrouper plusieurs changements dans un seul fichier, et un pipeline a été écrit pour nettoyer périodiquement le dossier des changements.

Leçon n°2

• La branche versioned, miroir de main, devenait de plus en plus difficile à cloner. Bien que seuls les fichiers CHANGELOG.md et CHANGELOG.json aient changé, cela entraînait le transfert de 125 Go supplémentaires de données git.
• Il a été découvert qu’un ancien code de packing validé par Linux Torvalds n’effectuait la compression qu’en comparant les 16 derniers caractères des noms de fichiers. Résultat : git comparait avec les fichiers CHANGELOG.md d’autres packages et renvoyait sans cesse l’intégralité des fichiers.
• La commande git repack -adf --window=250 a permis de réduire la taille du dépôt, puis la nouvelle commande git repack -adf --path-walk l’a fait passer de 178 Go à 5 Go.
• Le réglage git config --global pack.usePathWalk true a été ajouté afin que git push génère les bons deltas.

Conclusion

• Dans un monorepo de grande taille, si des fichiers au nom long comme CHANGELOG.md sont souvent mis à jour, il faut prêter attention à la fonctionnalité path walk.
• La commande git survey permet d’identifier les plus gros fichiers sur disque, les répertoires les plus volumineux une fois décompressés, etc.
• Microsoft développe des solutions pour faire évoluer les dépôts et les met à disposition à l’échelle mondiale.

Le résumé de GN⁺

• Cet article partage un retour d’expérience sur la réduction de la taille git d’un grand monorepo JavaScript. En particulier, il montre comment la résolution d’un problème dans un ancien code de packing git a permis de réduire fortement la taille du dépôt.
• Il fournit des informations utiles pour résoudre des problèmes liés à git dans les grands projets. Il explique notamment comment traiter les problèmes causés par les mises à jour répétées de fichiers comme CHANGELOG.md.
• Parmi les projets offrant des fonctionnalités similaires, on peut citer Buck de Facebook ou Bazel de Google. Ces outils peuvent aider à gérer efficacement de très grandes bases de code.

[GN⁺]

Commentaires Hacker News

• La nouvelle commande git-survey n’est pas encore incluse dans git.git. Elle a été ajoutée dans le fork Git de Microsoft

• En clonant nixpkgs, l’option --window 250 a réduit la taille à 1,7 Go. L’option --path-walk du fork Git de Microsoft l’a réduite à 1,9 Go

  • Les deux options ont réduit la taille à moins de la moitié de la taille initiale
  • Ce serait bien de pouvoir exécuter cela sur GitHub, et encore mieux si c’était hébergé d’une manière qui permette aux gens de le contrôler

• Certains utilisateurs en Europe disent qu’ils ne peuvent pas cloner de gros dépôts. Tant que des changements ne seront pas faits côté serveur, cela semblera impossible

• Un problème est survenu à cause d’une erreur où le nom de fichier n’incluait pas le chemin complet. Seuls les 16 derniers caractères étaient vérifiés

• Derick Stolee a écrit un blog sur la structure interne de Git. Il a été possible d’y apprendre beaucoup sur la façon de réduire la taille de git clone en local et dans le CI

• Hacker Git est amusant, mais on se demande s’il n’existe pas une façon de ne pas inclure 2 500 paquets dans un monorepo

• Il serait préférable que Microsoft utilise Azure DevOps en interne. On a l’impression que les services Azure ne fournissent des connecteurs natifs qu’à GitHub

• Avoir quelqu’un à proximité qui connaît bien la structure interne de Git est un bon avantage quand on travaille sur de gros projets

• Merci pour ce billet. Cela a beaucoup aidé le logiciel open source. Microsoft, GitHub et GitLab apportent beaucoup de bonnes choses

• J’aimerais mieux comprendre le problème de vérification des 16 derniers caractères et du chemin complet. Je me demande comment cela se relie à la compression delta, à l’index de paquets et à l’index multi-paquets