Pour l’association YesWiki, on discute en ce moment de comment quitter Github comme dépot de code, avec quelle stratégie (assurer une sync (et comment l’assurer), tout effacer chez github, aller chez un chaton, un hébergeur associatif, s’autohéberger, sur quelle forge logicielle, etc…).
Bref de multiples possibilités, et donc je me demandais si vous aviez traité ce sujet dans vos chatons, documenté le process, le cas échéant ca serait peut être intéressant de mutualiser voire de faire des guides chatons sur comment sortir des gafam : le cas github (et autres).
Chez ARN on utilise la forge code.ffdn.org malheureusement c’est difficile d’inscrire des personnes car il faut demander à l’équipe d’adminsys de la FFDN du coup ça ralentit la contrib je trouve…
Côté ynh, on attend la fédération annoncée pour 2023 dans plusieurs projets.
Je n’ai pas connaissance d’un mode d’emploi… ce serait bien que Hostea travaille dessus. L’objectif de https://forgefriends.org est de résoudre ce problème en fédérant les forges logicielles (qu’elles le veuille ou non), mais l’objectif n’est pas encore atteint, ça va prendre un peu de temps
Si la discussion pour YesWiki est publique, j’y contribuerais volontiers. La bonne solution dépend de pas mal de détails et ça commence par une question: est-ce qu’il y a les moyens humains et financiers de faire tourner et maintenir une forge dédiée?
J’utilise Fossil, qui est une forge et un DVCS décentralisé créé par les gens de SQLite, qui utilise SQLite. y’a des tickets, un forum, un chat, un wiki, un générateur de diagrammes, la gestion des comptes utilisateurs, bref ça fait un peu tout et c’est léger et contenu. C’est pas fédéré par contre. Mais contrairement aux autres forges, toutes les données de la forge sont décentralisées (tickets, wiki, forum, etc.) : quand tu clone le repository tu as tout sur ton ordi, et tu peux ensuite travailler hors ligne dessus, il y a un serveur web avec une interface, tout inclus. Si tu perds le repo principal, tu peux remonter un repo complet avec ta copie locale, les données seront les même. L’interface est pas mal, on peut naviguer dans l’historique très facilement. Perso je trouve Git très loin en terme d’UX et fonctionnalités
Par contre si on aime git, on peut ne pas aimer la philosophie de Fossil : on ne peut pas réécrire l’historique (pas de rebase, pas de force push), et généralement l’option autosync est activée (= chaque commit est poussé automatiquement au repo principal). C’est plus fait pour travailler en petite équipe. C’est simple à utiliser comme SVN, mais beaucoup plus puissant et pratique.
C’est un seul binaire à installer sur le serveur, et ensuite 2 lignes dans la conf apache pour renvoyer les requêtes vers le binaire en mode CGI, donc aussi très facile à installer. Fossil intègre un import/export Git donc on peut avoir le repo github synchronisé avec le Fossil.
@ljf : la fédération de forges promet en effet de belles choses, vivement 2023! Mais il nous faudra migrer ailleurs quand même, et on se pose la question de faut-il garder les repo sur Github ou partir totalement, voire laisser une archive et indiquer le nouveau dépôt principal. La fédération permettrait sans doute de synchroniser avec Github, mais on a t’on vraiment envie de continuer à garder ce lien?
@dachary : nos discussions ont lieu sur la canal Développement du framateam de YesWiki, donc ce n’est pas tout à fait public mais ouvert aux personnes avec un compte chez framateam. Ceci dit, j’ai partagé le lien vers cette discussion du forum et autant continuer par ici publiquement ?
Pour les parties moyens, comme toute les petites associations, c’est tres limité : l’asso provisionne un budget d’environ 1000 euros par an pour de la location de serveur et des backups, qu’on utilise pour héberger les sites et services autour de yeswiki (peut etre un futur chaton? ), avec une machine sous yunohost.
Les moyens humains sont bénévoles, et quand un chantier n’avance pas et/ou ne trouve pas de bénévoles, l’association peut décider d’attribuer un budget de prestation.
@bohwaz merci du partage sur Fossil, j’avais vu mentionné, mais jamais pratiqué, c’est une super feature le fait que les issues tickets et autres soient aussi décentralisés! Par contre à voir si cela ne fait pas trop de nouveaux trucs à apprendre, faut dire que git, même en étant inférieur à d’autres technos à un peu pris le lead sur les solutions de code versionning…
@dhebert super, merci de la proposition! C’est une bonne idée de mutualiser, après c’est toujours compliqué entre l’envie d’être totalement autonome, ou dans le cas d’une mutualisation comment gérer la gouvernance, les accès etc, on nous a suggérer de mutualiser avec Globenet aussi, mais compliqué de choisir du coup! J’aime bien l’idée aussi d’aller chez des chatons « spécialistes » comme hostea, mais ca pose toujours cette question de veut on la totale autonomie ou un bon rapport cohérence/temps à y passer/soustraitance-dépendance, pas facile à trancher!
Au dela du choix d’où aller, il y a pour moi aussi la question de qu’est ce qu’on perd (par exemple la visibilité sur github), et surtout quels sont les solutions faciles à maintenir et qui ont des options de migration un peu clé en main, voila ou j’en suis en regardant d’encore un peu trop loin :
gitlab à l’air d’avoir des importateurs depuis github bien foutus, mais importe t’il vraiment tout ? issues, wiki, organisations avec de multiples dépots, etc. meme gitea semble galèrer à quitter github cf. https://mastodon.cc/web/@gitea@social.gitea.io/108833229480663153
gitea semble facile à maintenir avec l’aspect binaire de Go, mais je n’ai pas testé, et ensuite sur les imports ou fonctions avancées comme la CI, je ne sais pas trop
fossil, je ne connaissais pas, mais là faut tout ré-apprendre, et niveau importation, pas d’idée
Vu qu’il y a déjà des services auto-hébergés et du matériel, je recommande:
Installer un GitLab
Prévoir un maximum de 4h par trimestre pour les mises à jour (c’est moins que ça mais un jour ça va bugger pour une raison ou une autre et ça va consommer du temps)
Migrer les projets avec l’import (c’est pas parfait mais ça aide)
Garder les projets sur GitHub en lecture seule
Il y aura une période d’inconfort de quelques semaines au plus: être à cheval sur deux plateformes, aller chercher ce qui a été oublié etc. Mais ça ne fait que s’améliorer avec le temps. Je n’ai pas idée de l’envergure de ce qui est à migrer mais je serais très surpris que GitHub soit plus qu’un souvenir dans un an. Et dans deux ans ça pourra probablement être effacé.
Mes 2cts
P.S. La visibilité sur GitHub est un mythe (intéressant a quel point il est répandu)
La discussion est super intéressante, je suis avec intéret, merci ! Je voudrais juste nuancer un tout petit point et partager un peu d’expérience à ce sujet :
Je ne sais pas si c’est un mythe ou pas, j’ai pas d’avis sur le sujet à part que, dans le libre on a tendance à s’auto invisibiliser. Notre expérience perso :
Garage, miroir automatique, 0 activité d’humain, 107 stars, on a jamais partagé un lien vers ce dépot avant aujourd’hui ni communiqué ou documenté ce truc. - https://github.com/deuxfleurs-org/garage
Le miroring automatique Gitea => Github + création de compte a pris en tout et pour tout : 30 minutes. Le coût est donc pas énorme, c’est une fonctionnalité de Gitea qui est super facile à setup.
L’idée c’est pas de faire dériver la discussion sur la question du sens des stars, ni le biais que Github introduit (les gens ont déjà un compte sur Github mais pas notre forge, etc.), bref c’est pas scientifique comme exemple. Mais j’ai la conviction que des gens ont entendu parler de nous via Github, et plus particulièrement via leur timeline Github - j’ai des données qualitatives sur la question en regard des données quantitatives sur les stars -, et clairement si on a une approche FOSS first, on va pas se priver d’un peu d’exposition sur les outils privateurs par pureté militante ^^
Le problème avec Gitea ce n’est pas let setup initial, c’est les mises à jour et les régressions. J’en suis content et je développe dessus tous les jours mais l’investissement en temps pour éviter de tomber sur des problèmes est nettement plus important que pour GitLab (cf le guide d’upgrade).
Pour ce qui est de YunoHost, on ne souhaite pas spécialement la fédération pour être sur github… C’est plutôt qu’on souhaite qu’une personne sans compte sur notre futur forge git, puissent suivre le repo, faire des pull request, des tickets, etc. EN fait, on espère un départ massif des libristes à ce moment précis.
Au niveau des forges il y a, encore assez peu de choix avec une centralisation.
La centralisation, même si elle à des inconvénients, à beaucoup d’avantages :
moins de coût énergétiques car il y a mutualisation des ressources
facilité de coopération avec une seule plateforme
facilité de navigation et de liens entre les projets d’une même instance
Pour le moment j’ai identifié en forges centralisées en France :
Si vous en avez d’autre je suis preneur pour alimenter ma liste d’alternatives.
Ce serait vraiment génial et ça permettrai d’avoir un compte unique et de ne pas en créer un sur chaque plateforme. Je sais que GitLab étudie le sujet depuis des années.
Concernant la migration vers GitLab j’ai fais quelques vidéos sur le sujet.
J’utilise gitea et woodpecker pour ma forge perso, et j’ai relativement peu de souci avec Gitea pour mon usage (eg des roles ansibles, des sites webs privés avec déploiement via la CI). J’ai automatisé la mise à jour via un script qui va directement voir sur github, chope le tarball, vérifie la somme de controle, etc et installe lance tout (et aussi un role ansible pour déployer tout). J’ai commencé avec la version 1.14.1 et j’ai eu 1 fois un souci à cause de l’upgrade. Ça a été corrigé assez vite, et le workaround n’était pas vraiment trop compliqué à mettre en oeuvre ou à déboguer (mais bon, c’est aussi mon quotidien ).
Le souci de Gitlab et Gitea, c’est à mon avis pas la forge ou son update, mais la gestion du spam qui devient vite une tache chronophage quand la forge est publique et que le projet a du succès, surtout si tu as une CI à coté, et ça ne va aller qu’en augmentant avec la fédération.
Et dans le cas de Gitlab, tu te retrouves assez vite à avoir besoin de features proprios pour éviter les abus comme Gnome l’a découvert y a 4 jours (une raison de plus de ne pas recommander un truc en open core).
Le cas de gnome est que des spammeurs proposent des patchs qui vont faire tourner des cryptominers sur la CI de Gnome, ce genre de choses. Mais j’ai aussi vu les spammeurs qui ouvrent des comptes juste pour ajouter des liens ou des pubs, etc. Et aussi les gens qui vont juste ouvrir des comptes et se servir de la forge comme stockage de données.
Je n’ai pas le souci parce j’ai une forge privé, mais si la forge propose une CI, il faut aussi faire attention à ce qui tourne dessus, à avoir des environnements jetables (ou facilement réinstallable à minima), à bien séparer les builds, etc. C’est un avantage de Github et sa CI intégré qui tourne sur Azure.
Et si tu veux avoir le même niveau de tranquillité chez toi, il faut quasiment installer ton propre cloud privé en installant Openstack, une tache que Dante Alighieri aurait décrit dans la Divine Comédie si le livre avait été sur l’informatique moderne. Et même la, tu n’es pas à l’abri d’une théorique attaque sur le hardware (j’insiste très fortement sur le « théorique », je mentionne par complétude, mais je doute que ça arrive).
L’autre solution, c’est de passer par un fournisseur Openstack tierce, mais je sais pas à quel point c’est compatible avec la charte CHATONS.
La 3eme solution, c’est de ne lancer la CI que si un membre du projet donne le feu vert, ou ce genre de choses. C’est un peu chiant à faire et ça rajoute de la friction (et la friction dans un projet libre, c’est mal™ cf la littérature existante sur le sujet, comme The art of Community), mais ça se fait.
Et pour woodpecker, ça marche bien, même si il manque encore quelque fonctions pour que je bouge les derniers workflows hors de github (taches périodiques, intégration avec gitea pour avoir un token éphémère et pousser des paquets).
Bonjour @Charlotte_dAlsace , nous n’avons pas encore choisi, cela passe par une décision collective des développeurs et on n’a pas encore eu de réunion pour s’en parler.
J’ai testé avec succès l’import de Github vers Gitlab, mais personnellement, bien qu’il soit moins élaboré, j’aimerais aussi tester gitea, qui me semble plus facile à maintenir car moins gros, et qui semble avancer plus vite sur le sujet de la fédération des forges.
On est encore aux décisions et tests, je partagerai les évolutions sur ce fil.
@mrflos Si tu choisis Gitlab en Mutualisé, on peut vous créer un espace et un compte gestionnaire de test sachant que nous avons déjà un client qui héberge sa forge chez nous.
Pour l’instant, nous n’avons pas encore regardé le côté mutualisation mais @frju365 m’en avait déjà parlé.
Je pense que le point le plus important concerne le sujet de la gouvernance sachant que nous sommes très souple et ouvert à toute collaboration.
Dominique
Il existe par exemple l’association Codeberg. Il est possible d’y avoir un compte gratuit ou de faire un don et de soutenir l’association en devenant membre. Codeberg utilise Gitea et est à l’origine de logiciels open source.
Gitea est un bel outil qui a la meilleure fonctionnalité de recherche. Mais les fonctionnalités de sauvegarde et de restauration sont très basiques. Par exemple, il n’y a pas de fonction de sauvegarde automatique, il est difficile de restaurer une sauvegarde. De plus, la routine d’installation initiale basée sur le Web de Gitea permet de sélectionner les fonctionnalités et les options que vous souhaitez activer ou désactiver dans la configuration. Après cela, un seul fichier de configuration gère tous ces ajustements et options.
Je suis en train de POC pour basculer sur Gitlab (l’instance Framagit), avec mon propre runner pour la CI.
Les résultats sont très positifs :
Le runner a été vraiment très simple à installer avec Docker, en quelques minutes c’était bon. Il tourne sur un petit VPS qui me servait déjà pour héberger des sites statiques et avait peu de charge en CPU.
Concernant Gitlab CI, je m’en sers principalement pour build / push (sur le registry Github pour le moment) des images Docker.
J’utilise aussi Gitlab CI pour faire tourner la version open source de Renovate, cf le projet renovate-runner, ça marche parfaitement bien !
Pour sortir complètement de Github, il me faudrait un registry open source, l’idéal ça serait de mettre quelque chose en commun, peut-être qu’il existe déjà quelque chose ?
Pour sortir complètement de Github, il me faudrait un registry open source, l’idéal ça serait de mettre quelque chose en commun, peut-être qu’il existe déjà quelque chose ?
Y en a des tonnes. Celui de Docker est libre. Celui de quay.io est libre. Gitea propose aussi le support des registres de conteneurs (tout comme Gitlab). Le souci n’est pas d’avoir du code libre, mais plus d’avoir des ressources gratos (surtout en terme de stockage, car j’ai le sentiment que c’est ce qui décolle assez vite).
Yes, c’est à ça que je pensais quand je parlais d’avoir quelque chose en commun, genre un registry CHATONS.
D’ailleurs, je me demande si y’aurait pas moyen de faire quelque chose avec Garage, le registry de Docker peut prendre du S3 en storage backend.
), avec une machine sous yunohost.
(nous réfléchissons à comment accueillir les projets FLOSS après avoir atteint notre rentabilité)