Passer de GitHub à Codeberg

19 février 2025

Pourquoi je quitte GitHub

GitHub appartient à Microsoft depuis 2018, mais bien que je n’aime pas Microsoft et que je n’utilise pas leurs produits, je ne m’en souciais pas vraiment. Principalement parce que je l’utilisais à peine. Et aussi parce que c’était avant que l’entreprise ne suce toutes nos données pour entraîner son IA sans nous demander la permission, et avant qu’elle ne soutienne Trump.

Voir ici pour en savoir plus sur la raison pour laquelle je quitte tous les services des GAFAM.

Mon utilisation de GitHub

Les années où je passais des heures à développer de l’open source (MoreUnit) sont loin (oué, c’est un peu triste). A cette époque, j’utilisais beaucoup Sourceforge, et seulement ensuite GitHub.

Même au boulot, j’ai arrêté d’utiliser GitHub en 2021.

Aujourd’hui, à part des pull requests très occasionnelles pour proposer une correction à un projet OSS quelconque, j’utilise parfois GitHub pour stocker des gists à inclure dans des articles de blog, et j’y garde d’anciens petits projets. Et j’utilise GitHub Pages pour héberger ce blog. Enfin, je l’utilisais. Puisque justement plus maintenant :-)

Mes besoins

Comme vous pouvez le voir, mes besoins sont assez basiques. Je n’ai même pas besoin de GitHub Actions. Et bien sûr, je peux supprimer certains des projets que je gardais jusqu’alors, ils ne sont pas d’un grand intérêt.

J’ai donc besoin d’une solution pour au moins héberger mon site web (ce qui, en vrai, ne nécessite pas de plateforme git), et pour partager occasionnellement des petits projets, même s’ils sont bateau, et si c’est super rare (un exemple).

Et je ne veux pas l’héberger moi-même.

Les alternatives que j’ai regardées

GitLab

Pour être honnête, si je voulais simplement remplacer GitHub par un truc équivalent et avoir une expérience similaire, je choisirais le plan gratuit de GitLab.com. J’utilise un plan payant depuis des années au travail, je me sentirais donc à l’aise.

Mais je n’aime pas particulièrement la façon dont le produit évolue, ni comment les fonctionnalités sont priorisées (J’ai blogué sur la partie CI dans le passé).

Et je ne pense pas spécialement que l’entreprise soit meilleure qu’une autre. Elle essaie tout le temps de rattraper GitHub, que ce soit une bonne idée ou non.

Bitbucket

Je ne connais pas Bitbucket. Mais je suis sûr que son plan gratuit ferait l’affaire.

Ceci dit, c’est fait par les gens qui ont créé Jira, donc… Atlassian a également créé Confluence et Bamboo, des produits que j’ai tous utilisés par le passé. C’est généralement - et c’est compréhensible - “enterprisey”, et je n’en suis pas spécialement amoureux.

Et, à nouveau, je ne pense pas que l’entreprise soit meilleure qu’une autre.

Sourcehut

Je trouve Sourcehut intéressant. Il s’agit d’un service open source. Il se soucie de la confidentialité et de l’efficacité. Pas de fioritures inutiles, mais quand même beaucoup de fonctionnalités. Il y a un hébergement web, et une plateforme CI si j’en ai besoin. Il propose également un équivalent des Gists de GitHub avec https://paste.sr.ht/.

Et je devrais payer 2$ par mois. Ce qui m’irait, en vrai.

Mais le service est en beta, et a priori toujours sujet à des changements, et même s’il n’y a pas de risque réel pour moi, je ne veux pas revenir régulièrement sur mon installation à cause de ça.

Sourceforge

En vrai, je n’ai pas cherché à savoir ce qu’il en était. J’ai ouvert leur site web et il avait la même tête que quand je l’utilisais… en 2009. Et même à cette époque, je n’aimais pas leur interface. Du coup, je ne sais même pas ce que le service propose.

Je pourrais continuer longtemps

Il existe beaucoup de plateformes basées sur git (et pas que), et c’est très bien ! Mais je n’ai pas essayé de les passer toutes en revue. La sélection ci-dessus m’a suffi, avec Codeberg, que je présente rapidement ci-dessous.

Mon choix: Codeberg

Codeberg présente des similitudes avec Sourcehut, que j’ai mentionné plus haut. Il est hébergé en Europe et se préoccupe de la protection de la vie privée. Il est open source et soutient les logiciels open source. En fait, votre code doit être open source pour être hébergé sur Codeberg.

Il ressemble à GitHub ou GitLab et propose des pull requests, un système de tickets, un wiki, etc. Il offre un hébergement web très basique (plus d’informations à ce sujet plus tard). Et je peux postuler pour la partie CI si j’en ai besoin… mais à la condition que mon code soit effectivement open source, qu’il ait un objectif clair, et qu’il fasse un usage raisonnable des ressources du service (voir les critères).

Il n’est pas obligatoire de payer pour utiliser Codeberg, mais le service repose sur des dons et il est donc préférable d’en faire un de temps en temps.

Enfin, je trouve que l’interface utilisateur pour les repositories ressemble suffisamment à celle de GitHub ou de GitLab pour que les gens ne soient pas surpris s’ils reçoivent un lien vers un projet hébergé ici.

Migrer des repositories de GitHub vers Codeberg

Bon déjà, vous pouvez probablement supprimer les dépôts dont vous ne vous souciez plus. Il n’est pas nécessaire de les migrer, n’est-ce pas ? J’ai supprimé la plupart des miens.

Codeberg vous propose de migrer automatiquement vos dépôts GitHub, y compris les issues, les pull requests, les releases, les pages wiki, etc. Tout ce dont il a besoin, c’est d’un access token avec les bonnes permissions.
Il suffit de suivre les étapes documentées ici.

Mais il y a un petit hic : vous devez le faire repo par repo.

Si, comme moi, vous avez principalement des repos avec du contenu mais rien d’autre (issues, pull requests, etc.), vous pouvez essayer ce script (documentation), qui fonctionne très bien. Il migrera tous vos dépôts en une seule fois (ou une sélection de repos).

Migrer des Gists vers Codeberg

Pour autant que je sache, Codeberg ne fournit pas de service de “paste” ni d’équivalent aux Gists de GitHub.

Cela ne me dérange pas vraiment : un simple repo contenant une collection de fichiers peut faire l’affaire.

J’ai donc récupéré tous mes gists en utilisant cet outil (GitHub TakeOut), et j’ai poussé le résultat vers Codeberg en tant que nouveau repo :

git clone https://github.com/devarda/github-takeout.git
cd github-takeout
npm install
# créez d'abord un access token avec les bonnes permissions
export GITHUB_TOKEN=...
npm run download-all
mv downloaded-gists ../gists
cd ../gists
git init
git add .
git commit -m "Import gists from GitHub"
# créez un repository sur Codeberg, et poussez tout ça dedans !

Migrer un site de GitHub Pages vers Codeberg Pages

Le principe, simple comme bonjour…

Comme GitHub, Codeberg propose de publier :

un site pour votre utilisateur ou votre organisation, à partir de la branche main d’un dépôt spécifique nommé pages (vs votre_nom.github.com), accessible à votre_nom.codeberg.page (vs votre_nom.github.io)
un site pour n’importe quel dépôt, à partir d’une branche orpheline dédiée nommée pages (vs gh-pages), accessible à votre_nom.codeberg.page/votre_repo (vs votre_nom.github.io/votre_repo).

Contrairement à GitHub, Codeberg vous permet seulement de publier des fichiers statiques. Il n’y aura pas de build “magique” Jekyll pour votre site. Mais c’est assez facile à gérer, comme nous allons le voir. Vous pouvez garder votre Markdown :-)

Comme GitHub, Codeberg Pages vous permet d’utiliser un domaine personnalisé, en créant un fichier .domains à la racine de votre dépôt (vs un fichier CNAME), et en configurant le ou les enregistrements DNS appropriés.

La procédure complète est très bien résumée ici.

… sauf quand il ne l’est pas

Alors que j’ai pu créer un site pour mon utilisateur en utilisant un repository nommé “pages”, je ne suis pas parvenu à créer de site pour un autre repo.

Comme je n’en avais pas vraiment besoin, je suis passé à autre chose.

Comment migrer votre site

Avertissement préalable : j’ai eu des problèmes de disponibilité avec Codeberg Pages, comme décrit plus loin dans cet article. Donc vous voudrez peut-être jeter un coup d’oeil à la page Codeberg Service Status pour décider si c’est bon pour vous, avant de migrer.

Publication

Créer un repo pages sur Codeberg, sans premier commit.
Localement, pullez votre dépôt d’utilisateur GitHub (votre_nom.github.com).
Si vous utilisiez Jekyll, renommez vos branches, car la branche main devra contenir le résultat d’un build local fait par Jekyll. Procédez comme suit :
- Installez Jekyll (instructions). À ma grande surprise, la dernière version (v4.4.1 au moment où j’écris ces lignes) a parfaitement fonctionné pour construire mon ancien site qui se servait d’une très ancienne version (1.x).
- A partir de votre branche main (ou master, ou autre), créez une branche pour les sources Jekyll de votre site. J’ai appelé la mienne sources :
```
git switch --create sources
```
- Supprimez à présent votre branche main précédente :
```
git branch --delete --force main
```
- Et recréez-en une, mais orpheline (orphan) :
```
git switch --orphan main
```
- Retournez sut votre branche sources :
```
git switch sources
```
- Ajoutez-y ce script, et personnalisez-le si vous le souhaitez:
```
curl --location --remote-name https://codeberg.org/ndemengel/pages/raw/commit/b3e4373ba21884797a0ef7075c3adac444552aac/build-and-publish.sh
chmod u+x build-and-publish.sh
git add build-and-publish.sh
git commit "Add build script"
```
- À chaque fois que vous changez quelque chose et voulez publier votre site, lancez le script:
```
./build-and-publish.sh
```
  Ça construira le site, commitera le résultat dans la branche main, et poussera cette branche vers Codeberg.
  On pourrait modifier ce script pour qu’il commit et pousse également la branche sources. Ou bien, on pourrait en faire un hook de pre-push, qui l’exécuterait à chaque fois que la branche sources est poussée.
À présent, attendez que votre site soit disponible sur votre_nom.codeberg.page. Vous pouvez le faire en exécutant la commande suivante de manière répétée et en regardant le résultat:
```
curl --include --silent https://your_name.codeberg.page | head -n 25
```
Vous devriez obtenir un code de statut 200, puis le contenu de votre site :
```
$ curl --include --silent https://your_name.codeberg.page | head -n 25
HTTP/1.1 200 OK
[..]
<!DOCTYPE html>
  [..]
  <title>Le titre de votre page!</title>
```

Utiliser un domaine personnalisé

Si vous voulez utiliser un nom de domaine personnalisé, ajoutez un fichier .domains à la racine de votre branche main, contenant votre nom de domaine (ou plusieurs). Par exemple, le mien est n.gridem.fr.
Committez, et poussez votre branche main.
Note : si vous utilisez le script build-and-publish.sh présenté ci-dessus, placez le fichier .domains dans la branche sources, et le script le copiera dans main lorsqu’il sera exécuté.
Encore une fois, attendez que les changements soient visibles, en exécutant :
```
curl --include --silent https://your_name.codeberg.page | head -n 25
```
Vous devriez obtenir une redirection, avec un code de statut 307 :
```
$ curl --include --silent https://your_name.codeberg.page | head -n 25
HTTP/2 307 
[..]
location: https://your.domain.name/
[..]
<a href="https://your.domain.name/">Temporary Redirect</a>.
```
Il est maintenant temps de mettre à jour votre enregistrement DNS pour votre.nom.de.domaine, pour en faire un alias de votre_nom.codeberg.page.
Comme j’utilise un sous-domaine, tout ce que j’ai eu à faire a été de changer mon enregistrement CNAME pour n.gridem.fr de ndemengel.github.io vers ndemengel.codeberg.page.
Si vous utilisez un domaine apex, vous devrez mettre à jour (ou créer) à la fois un enregistrement ALIAS (ou A & AAAA) et un enregistrement TXT, comme expliqué sur https://codeberg.page/.
Pour observer vos changements, vous pouvez utiliser la commande dig, comme suit :
```
dig your.domain.name +nostats +nocomments
```
Pour un enregistrement CNAME, vous voulez voir quelque chose comme ce qui suit :
```
$ dig autoconfig.gridem.fr +nostats +nocomments 

[..]
your.domain.name.	60	IN	CNAME	your_name.codeberg.page.
```

Note : Je vous conseille d’utiliser un TTL (time to leave) court pour vos enregistrements DNS au début, genre 60 secondes. Comme ça, si vous vous trompez, la correction se propagera assez rapidement.

Mais… la disponibilité de Codeberg Pages

J’ai décidé de migrer la semaine dernière alors que Codeberg subissait des attaques DDOS constantes. Je ne sais pas si c’est lié, mais la disponibilité des pages Codebase était d’environ 80% pendant cette période.

En conséquence, mon site était soit très lent à charger, soit tout simplement inaccessible.

Bien sûr, je ne peux pas les blâmer. D’abord parce que Codeberg ne me doit rien. Et aussi parce que les personnes qui s’en occupent ont tout mon soutien, elles ont ramé!

Mais j’ai décidé de publier temporairement mon site web sur un espace très réduit (10MB !) que j’ai chez Infomaniak. Au moment où j’écris ces lignes, il est toujours là, et je verrai plus tard si je peux faire un nouvel essai avec Codeberg Pages.

Mais les sources sont toujours dans mon dépôt pages sur Codeberg, et le site web est toujours construit et publié de la même manière. Seulement, je copie maintenant aussi le résultat du build vers Infomaniak.

Dans le processus, j’ai dû changer ma configuration DNS à nouveau (en utilisant un enregistrement A cette fois), et modifier un bon vieux fichier .htaccess aussi, pour exposer le contenu d’un dossier spécifique en fonction du sous-domaine qui est interrogé :-).

J’ai également dû mettre à jour le certificat que j’utilise sur Infomaniak pour mes domaines (gridem.fr et quelques sous-domaines), pour inclure le sous-domaine n utilisé par ce site web.

Pour une raison inconnue, le nouveau certificat a mis une éternité à être exposé, et j’ai donc dû attendre qu’il soit prêt avant d’appliquer ma nouvelle configuration DNS. Sinon, les navigateurs se seraient plaints du certificat de mon site.

Au cas où vous seriez confronté au même problème, voici comment j’ai surveillé le certificat exposé par Infomaniak, pour détecter quand il incluait finalement le nouveau sous-domaine. Cette astuce repose sur le fait que j’ai une petite page (certes pas très utile) déjà servie par Infomaniak, sur gridem.fr :

openssl s_client -showcerts -servername gridem.fr -connect gridem.fr:443 <<< "Q" \
  | openssl x509 -text \
  | grep -E -A2 '(Alternative|Validity)'

Je n’ai eu qu’à attendre que la sortie affiche de nouvelles dates dans la section “Validity” et que n.gridem.fr apparaisse dans la section “Subject Alternative Name”.

C’est à peu près tout

Les instructions de cet article devraient être assez similaires pour migrer vers un autre service. J’espère que ce retour d’expérience sera utile à quelqu’un !