Migrer de GitHub vers Codeberg, la méthode pour les paresseux

• En déplaçant certains projets de GitHub vers Codeberg, l’auteur explique comment commencer une migration avec un minimum d’effort
• Grâce à la fonction d’import de dépôt de Codeberg, il est possible d’effectuer une migration complète incluant les issues, les PR et les releases, avec une interface et un workflow similaires à GitHub
• L’hébergement de pages statiques peut être remplacé par codeberg.page, et il existe aussi des alternatives comme grebedoc.dev ou statichost.eu
• La plus grande difficulté est la mise en place de l’environnement CI : il faut renoncer aux runners macOS et au volume d’exécution gratuit de GitHub, avec des alternatives comme Forgejo Actions ou Woodpecker CI
• Après la migration, il est proposé de conserver le dépôt GitHub en archive en lecture seule ou en miroir, afin de ne pas couper totalement le lien avec l’écosystème open source

---

Processus de migration de GitHub vers Codeberg

• En s’appuyant sur l’expérience du début de migration de certains dépôts de GitHub vers Codeberg, l’auteur décrit la difficulté réelle du processus et sa praticité
  • Il avait repoussé cette migration en pensant que Codeberg n’était pas encore prêt, mais selon les projets, elle peut être étonnamment simple
  • L’objectif n’est pas une configuration parfaite, mais de trouver la manière la plus simple de commencer à migrer

• Migration des dépôts et des issues

  • Codeberg propose une fonction d’import de dépôt (import) GitHub, permettant de migrer les issues, les PR, les releases et leurs artefacts
    • Dans ce processus, les numéros d’issue, les labels et les informations sur les auteurs sont conservés tels quels
    • L’interface de Codeberg est presque identique à celle de GitHub, ce qui rend l’expérience bien plus simple que les procédures complexes souvent nécessaires pour migrer d’un autre gestionnaire d’issues vers GitHub

• Hébergement de pages statiques

  • Si vous utilisiez GitHub Pages, vous pouvez utiliser codeberg.page comme solution de remplacement
    • Il n’y a pas de garantie officielle de disponibilité (SLO), mais l’auteur indique n’avoir en pratique jamais constaté d’interruption
    • Le fonctionnement consiste à pousser du HTML dans une branche, avec une structure similaire à GitHub Pages
    • Des alternatives comme grebedoc.dev ou statichost.eu sont également possibles

• Difficultés liées à l’environnement CI (intégration continue)

  • La partie la plus délicate de la migration est la mise en place de l’environnement CI
    • GitHub fournit des runners macOS gratuits et une capacité d’exécution illimitée pour les dépôts publics, mais il faut y renoncer sur Codeberg
    • Comme solution, il est possible d’utiliser la cross-compilation selon le langage et l’auto-hébergement des runners Forgejo Actions

  • Forgejo Actions vs Woodpecker CI

    • Sur Codeberg, Woodpecker CI est plus stable, mais Forgejo Actions offre un environnement plus familier aux utilisateurs de GitHub Actions
    • L’interface et la syntaxe YAML sont presque identiques, et la plupart des workflows GitHub Actions existants fonctionnent tels quels
    • Par exemple, si vous utilisiez uses: dtolnay/rust-toolchain dans GitHub Actions, dans Forgejo Actions, il suffit de le remplacer par uses: https://github.com/dtolnay/rust-toolchain
    • La documentation actuelle de Forgejo Actions sur Codeberg n’est pas à jour, et une PR existe à ce sujet

  • Si un runner macOS est nécessaire

    • Si un build macOS est indispensable, il est possible de continuer à utiliser GitHub Actions et de mettre en place un miroir des commits du dépôt Codeberg vers GitHub
    • Il est possible de configurer Forgejo Actions pour qu’il interroge l’API GitHub et synchronise l’état de la CI vers Codeberg
    • D’autres services de CI proposant des builds macOS ont aussi été testés, mais leur intégration avec Codeberg n’est pas plus simple que GitHub Actions

• Que faire du dépôt GitHub

  • Après la migration, le dépôt GitHub est archivé après modification du README
    • Il est aussi possible de configurer Codeberg pour pousser les commits vers GitHub, mais dans ce cas, les utilisateurs peuvent encore ouvrir des PR et commenter les issues
    • Certains désactivent la fonction issues du dépôt GitHub, mais dans ce cas toutes les issues disparaissent en 404 et il n’est pas possible de désactiver les PR
    • Par exemple, le dépôt libvirt/libvirt utilise une GitHub Action qui ferme automatiquement toutes les PR
  • Cette approche peut avoir un impact négatif sur l’auto-hébergement et l’écosystème open source dans son ensemble
    • Les utilisateurs perdent leur motivation à améliorer l’optimisation des builds ou la fréquence de téléchargement des fichiers de release
    • Pendant la période de transition, il est aussi possible d’envisager un miroir en lecture seule ou l’utilisation conjointe de GitHub Pages et GitHub Actions

[GN⁺]

Avis Hacker News

• Je n’ai rien contre Codeberg en soi, mais ce n’est pas un remplaçant complet de GitHub
  Il y a beaucoup de limitations pour héberger des dépôts de code personnels ou des scripts expérimentaux, et les dépôts privés sont limités à 100 Mo
  Il n’est pas non plus possible d’héberger un site web comme avec GitHub Pages. Pour ce type d’usage, une alternative réaliste consiste à auto-héberger Forgejo
  Tout cela est bien expliqué dans la FAQ de Codeberg

  • Il est aussi possible d’héberger un site web sur Codeberg via la fonctionnalité Codeberg Pages
  • J’héberge moi-même mon site web sur Codeberg Pages. L’information ci-dessus est incorrecte → documentation Codeberg Pages
  • J’ai du mal à être d’accord avec l’idée que « faire tourner son propre serveur git est trop lourd ». Si on veut simplement un endroit où pousser du code, un simple serveur SSH suffit
  • Le projet Code Storage créé par Pierre est intéressant comme serveur git orienté API qui réduit cette charge d’exploitation
  • (Petit coup de pub) Je développe une alternative à GitHub appelée Monohub. Les dépôts privés sont inclus par défaut, et les PR sont prises en charge. Exemple de dépôt public

• Si je mets mes projets OSS sur GitHub, c’est pour une raison simple — la communauté s’y trouve
  Si c’était juste pour stocker du code, je l’hébergerais moi-même via SSH ou SFTP

  • Le fait que la communauté reste uniquement sur GitHub relève du problème de l’œuf ou de la poule. Au final, il faut bien que quelqu’un migre d’abord vers une autre plateforme pour que l’écosystème bouge
    Moi, je ne publie que sur mon instance Gitea personnelle, et je ne me soucie ni des étoiles ni de la promotion
  • Rester sur GitHub, c’est simplement accepter une dépendance fermée au sein de la communauté FOSS. Au contraire, les politiques de GitHub poussent les gens à partir
  • Certains projets ne permettent même pas de contribuer sans compte GitHub. Par exemple, le problème de crates.io n’est toujours pas résolu après 10 ans, et le Reservoir de Lean exige au moins 2 étoiles GitHub. Cela ressemble à un renforcement de la dépendance à Microsoft
  • GitHub fournit gratuitement beaucoup de ressources CI. En particulier, il n’existe pratiquement pas d’alternative aux runners macOS. Grâce à cela, on peut tester dans des environnements variés
  • Moi aussi, j’ai commencé à héberger Git sur mon serveur perso pour m’éloigner de GitHub, mais la dopamine du push de commit d’autrefois a disparu. J’ai l’impression que l’open source a perdu de son attrait en se marchandisant

• Je gère tous mes projets personnels en auto-hébergeant Forgejo. GitHub ne me manque absolument pas
  On peut aussi limiter l’accès avec Tailscale pour bloquer les crawlers IA

  • Moi aussi, j’exploite Forgejo moi-même depuis plusieurs années. J’ai même écrit un tutoriel d’installation et j’ai récemment migré vers deux Raspberry Pi chez Hetzner. C’est plus rapide et plus stable que GitHub
  • Avant, j’utilisais GitLab, mais Forgejo est un binaire Go unique bien plus léger, donc beaucoup moins gourmand en ressources. Il tourne facilement avec Docker, et c’est aussi très amusant de bidouiller soi-même les fonctionnalités
  • J’ai installé Forgejo quand la création de comptes agents a été bloquée sur GitHub, et en 15 minutes j’ai directement ajouté la fonctionnalité « masquer les fichiers Viewed » dans la revue de PR
  • Comme de gros projets OSS ont récemment migré vers Forgejo, j’ai suivi le mouvement, et pour l’instant j’en suis très satisfait
  • J’ai aussi installé un runner Forgejo avec Docker pour faire tourner la CI. Il y a un registre intégré, donc je déploie mes applications sous forme d’images Docker

• À l’avenir, évaluer les alternatives à GitHub va devenir de plus en plus important
  Mais GitHub a imposé des standards pour la CI et les builds multi-architectures, ce qui rend la concurrence difficile pour les alternatives portées par la communauté

  • La CI n’a pas besoin d’être liée à GitHub. En réalité, la plupart des systèmes de CI ne sont que de simples exécuteurs de commandes. Pour une petite équipe, on peut très bien fonctionner sans CI
  • Je ne vois pas pourquoi exploiter sa propre CI serait irrationnel. Séparer le dépôt et la CI ne pose aucun problème
  • Pour moi, ce qui compte davantage que la CI, c’est l’expérience PR et revue de code. GitHub reste encore très inconfortable sur plusieurs points, et son système d’issues est resté au niveau d’il y a 20 ans
  • Ce genre de couche centralisée vient au fond d’une volonté de contrôle. On peut très bien développer avec plaisir dans un workflow distribué centré sur le local

• GitHub fournit beaucoup de choses « gratuitement », mais en échange il y a de fortes chances que cela serve à la collecte de données et à l’entraînement
  Codeberg ne prend pas en charge les dépôts privés, donc il n’est pas non plus possible d’empêcher Copilot de parcourir les dépôts publics
  D’après la FAQ de Codeberg, si l’on a besoin de projets privés, il est recommandé d’auto-héberger Forgejo

  • Pourtant, mon dépôt Codeberg est bien configuré en privé. Donc ce n’est peut-être pas totalement impossible

• Notre entreprise a complètement migré de GitHub vers GitLab auto-hébergé
  Comme c’est placé derrière Tailscale, il n’y a pas la contrainte du SSO, et les runners CI tournent sur EKS et sur un cluster GPU. Je peux aider ceux qui réfléchissent à une migration similaire

  • Je suis curieux de savoir si Forgejo a aussi été envisagé. GitLab est fort sur la CI/CD de niveau entreprise, mais pour de petits projets Forgejo semble être un choix plus léger
  • Je me demande aussi si GitLab auto-hébergé prend en charge des fonctions comme le provisionnement automatique des utilisateurs (SCIM)

• Dire simplement « remplaçons GitHub » n’a pas beaucoup de sens. Il faut de nouvelles habitudes et une nouvelle proposition de valeur
  De la même façon que GitHub a remplacé SourceForge, la plateforme de la prochaine génération devra relier en temps réel l’écriture de code et la collaboration
  Par exemple, cela pourrait ressembler à Google Docs avec un commit créé à chaque prompt

  • Mais il y a aussi de fortes raisons géopolitiques. En Europe notamment, les mouvements visant à réduire la dépendance aux technologies américaines sont actifs
  • Avec la récente controverse autour de Copilot, la confiance a vacillé et un mouvement de départ de GitHub est apparu
  • Pour moi, l’important n’est pas seulement la fonctionnalité, mais aussi la disponibilité (uptime). Ces temps-ci, GitHub n’atteint même pas 99 %

• Codeberg est idéal en théorie, mais en pratique il y a de gros problèmes de stabilité
  En l’exploitant sans Cloudflare, le service est vulnérable aux attaques DDoS et subit des pannes fréquentes. Quand on ne peut pas accéder au dépôt distant en plein développement, c’est vraiment frustrant

  • J’utilise GitHub ou Codeberg simplement pour le partage de code asynchrone. Même si le distant tombe, il faut pouvoir continuer à travailler en local
  • Je n’aime pas Cloudflare, mais en pratique c’est indispensable pour se défendre contre le trafic de bots et les attaques. Les services alternatifs étaient au contraire encore plus souvent bloqués ou instables. On ressent fortement l’écart entre les principes et la réalité
  • Si l’on regarde le suivi de disponibilité de GitHub, on est autour de 90 % sur les 90 derniers jours. Au contraire, Codeberg est plus stable
  • Mon serveur git personnel a lui aussi vu ses performances se dégrader à cause du scraping indiscriminé des crawlers IA. J’ai fini par bloquer toutes les IP des grandes entreprises
  • Le cœur de git, c’est la nature distribuée. Même si le distant tombe, la dernière version doit exister en local

• Depuis le rachat par Microsoft, je n’utilise presque plus GitHub. Le workflow simple basé sur l’e-mail de Sourcehut me convient mieux
  Pour la CI aussi, je pense qu’un système simplement fondé sur des commandes exécutables en local est largement suffisant

• Un dépôt de code devrait par nature avoir une structure distribuée et fédérée
  Grâce au système de signatures cryptographiques (GPG/SSH) de git, on peut séparer la confiance dans le dépôt de la confiance dans les commits
  Il suffit de centraliser un serveur de clés et la gestion des espaces de noms, et de distribuer tout le reste

  • Radicle est justement un projet qui vise cet hébergement git distribué
  • Mais la plupart des développeurs ne savent pas bien gérer leurs clés de signature
  • C’est pour cela que des protocoles fédérés comme Tangled ou ForgeFed sont en cours d’intégration dans Forgejo
  • git-bug est aussi une approche intéressante. Je ne l’ai pas encore essayé, mais cela semble prometteur