Garnix va fermer

• garnix prévoit d’arrêter son service d’hébergement le 15 juillet 2026 dans le cadre de sa transition pour rejoindre Shopify
• La base de code de garnix sera publiée en open source, afin que les utilisateurs puissent migrer vers leur propre instance ou une instance partagée
• Les utilisateurs intéressés par l’exploitation d’une instance communautaire publique peuvent contacter l’équipe garnix, qui souhaite également ouvrir la discussion sur ce sujet
• Le 15 juillet 2026, toutes les données utilisateur seront supprimées, y compris les artefacts de build
• Les données et artefacts de build à conserver devront être téléchargés manuellement avant la date de fermeture, l’annonce actuelle étant partagée sous forme de citation d’un e-mail

---

Fermeture du service et publication du code

• garnix rejoint Shopify et, dans le cadre de cette transition, mettra fin au service garnix hébergé le 15 juillet 2026
• La base de code de garnix sera publiée en open source afin de permettre aux utilisateurs de migrer vers leur propre instance ou une instance partagée
• Les utilisateurs intéressés par l’exploitation d’une instance communautaire publique peuvent contacter l’équipe garnix

Données utilisateur et préparation de la migration

• Le 15 juillet 2026, toutes les données utilisateur seront supprimées, y compris les artefacts de build
• Les données ou artefacts de build à conserver doivent être téléchargés manuellement avant la date de fermeture
• L’annonce de fermeture n’a pas été confirmée sur garnix.io et est partagée sous forme de citation du contenu d’un e-mail reçu depuis [e-mail]
• L’équipe garnix a remercié la communauté pour son soutien, y compris les dons et retours à l’époque d’Open Collective, et mentionne comme membres de l’équipe Alex David, Sönke Hahn et Julian K. Arni

[GN⁺]

Avis sur Lobste.rs

• C’est dommage ! J’avais vraiment adoré l’article expliquant comment résoudre les problèmes de déploiement progressif en intégrant les URL de dépendance des services directement dans le build du service
  https://garnix.io/blog/call-by-hash/

• Pour ceux qui se demandent ce qu’est Garnix :
  Garnix est un service de CI pour les dépôts GitHub Nixifiés basés sur flake
  Source : https://github.com/garnix-io/garnix-ci#garnix

• Garnix était de très loin le meilleur système de CI que j’aie utilisé jusqu’à présent
  Quand GitHub Actions était encore en train de chercher un runner, Garnix avait déjà fini le build, et même mon projet Rust de complexité moyenne se terminait en général en moins d’une minute
  C’était encore plus rapide quand je ne modifiais que la documentation, et la doc était réellement buildée
  Bien sûr, c’est grâce à Nix, mais Garnix avait vraiment très bien réussi cette intégration
  Une CI intégrée au système de build peut fonctionner bien mieux qu’une approche qui retélécharge à chaque fois depuis S3 une demi-tarball de système de fichiers pour recoller un cache
  En plus, comme c’est basé sur Nix, on build exactement la même chose qu’en local, donc pas de longue boucle de retour du genre « corriger une faute de frappe dans le yaml, push, attendre 10 minutes, voir l’erreur suivante, ajouter une sortie de debug, re-push... »
  Si ça build en local, ça marche aussi en CI

• Dommage. J’avais vu quelques problèmes bizarres la semaine dernière environ, mais je n’y avais pas trop prêté attention
  Le fait que seul GitHub soit pris en charge me gênait un peu, mais ça restait un excellent service
  Je pense regarder la version open source ce week-end pour voir si l’auto-hébergement est réaliste, et si vous connaissez des alternatives pour les builds Nix, je suis preneur

• J’utilise garnix depuis son lancement, donc ça fait vraiment quelque chose de le voir s’arrêter
  Si quelqu’un connaît une solution de CI Nix ou un outil auto-hébergeable, ça m’intéresserait
  J’utilisais surtout garnix comme cache, et j’avais aussi mis en place un workflow d’auto-merge basé sur l’état public des checks

  • tangled.org devrait publier bientôt quelque chose de similaire. Ce sera probablement auto-hébergeable
  • comme garnix semble devenir open source, ça pourrait aussi être une option pour l’auto-hébergement
    Je n’étais pas client et je n’utilise Nix qu’à la maison, mais je compte quand même regarder de près comment l’auto-héberger

• Sans le passage suivant, ce serait complètement hors sujet :
  « Mais nous publions aussi le code de garnix en open source, visible ici »
  Je trouve que ce point est pertinent et intéressant
  Dans mon entreprise, on mise à fond sur Nix, et ça me laisse des sentiments assez partagés
  La plus grande partie de ce ressenti négatif vient du fait que Nix est une technologie vraiment excellente, tout en donnant encore l’impression d’un très jeune artefact alien
  Il reste énormément de choses passionnantes et utiles à faire autour de Nix, donc c’est enthousiasmant
  Adopter Nix, c’est aussi renoncer à pas mal de fonctionnalités de confort accumulées depuis longtemps par les plateformes existantes, donc j’examinais plusieurs outils de l’écosystème Nix, dont Garnix
  Dans les faits, dans l’entreprise, on investit beaucoup plus d’efforts dans des fonctionnalités « de base » qu’on aurait autrement eues gratuitement
  Par exemple, faire tourner la validation dans GitHub Actions est plus complexe que pour un projet classique, et des éléments comme le cache ou la parallélisation sont essentiels pour obtenir des builds robustes et rapides
  J’ai l’impression que les entreprises qui font progresser l’écosystème Nix vont soit beaucoup grandir, soit que quelqu’un construira quelque chose de révolutionnaire sur les épaules des géants de Nix
  Malheureusement, Garnix donne l’impression d’être l’un de ces pionniers absorbés par une organisation plus grande

  • Ce qui est amusant, c’est que Nix n’est pas si jeune que ça
    C’est apparu plusieurs années avant Docker ; c’est juste une technologie qui a fleuri tardivement et n’a gagné en popularité que récemment

• Maintenant que garnix est open source, je me demande à quel point il serait difficile de le détacher de GitHub
  Le détacher des flakes devrait être assez facile. Les flakes ne sont pas réels et ne peuvent pas vous faire de mal

  • À chaque fois que je voyais garnix, je me sentais comme Carlo Tentacule regardant Bob l’éponge et Patrick s’amuser par la fenêtre avec envie
    Cette possibilité me réjouit clairement

• Petite digression : j’essaie de passer la CI à Nix, mais l’environnement de dev/CI est énorme
  La raison principale, c’est qu’il contient plusieurs navigateurs complets, et je n’ai pas trouvé de moyen d’éviter nix build ou la restauration du cache
  Même restaurer 10 Go sur une connexion à 1 Gbit, c’est trop lent
  Avec Docker, ce problème est résolu si on utilise des runners auto-hébergés
  Il suffit de construire une image Docker et de la garder en cache sur l’hôte où démarre le runner CI
  Mais avec Nix, je ne sais pas comment on est censé faire ça
  Il me faudrait un moyen de partager un nix store contenant déjà tout ce qui est nécessaire à l’environnement de développement, et ce store devrait être dérivé du véritable flake d’environnement de dev versionné dans le dépôt
  On dirait bien que ça n’existe pas, non ?

  • Je ne suis pas sûr de comprendre. Si vous auto-hébergez le runner et que vous pré-remplissez /nix/store avec ce dont ce workflow a besoin, alors, comme pour une image OCI, tout est simplement déjà là, non ?
    Dans mon ancien poste, on faisait tourner nos propres runners GitLab et on les préchauffait en instanciant un ensemble récent d’artefacts de build avant de les mettre en service
    Ensuite, les jobs utilisaient simplement ce qui était déjà en cache dans /nix/store