Comment migrer de Gitea vers Forgejo sans casser vos dépôts

Vous arrêtez Gitea, installez Forgejo, copiez app.ini et votre répertoire de données, et démarrez le service comme tous les guides de migration le décrivent. L'interface web apparaît. Puis la migration de base de données échoue, ou pire, Forgejo refuse de démarrer parce que votre version de schéma est trop récente pour qu'il la comprenne. Vous êtes sur Gitea 1.23 ou plus récent, et la simple mise à niveau sur place que tout le monde documente ne s'applique plus à vous.

Forgejo est devenu un hard fork de Gitea début 2024, et les deux projets ont depuis divergé au niveau du schéma de base de données. La façon de migrer Gitea vers Forgejo dépend désormais entièrement de votre version de Gitea. Ce guide vous donne le chemin exact pour votre version, les commandes complètes pour les installations natives et Docker, les contournements pour Gitea 1.23+, ainsi qu'une checklist de vérification, afin que vous migriez sans perdre de dépôts, d'issues ou d'utilisateurs.

En bref

• Le seuil de version est bien réel. Forgejo v10.0 a été la dernière version à prendre en charge une mise à niveau directe et transparente depuis Gitea. Gitea v1.22 est la version la plus élevée pouvant emprunter le chemin direct pris en charge.
• Sur Gitea v1.22 ou antérieur : migrez d'abord vers Forgejo v10.0.x, puis mettez à niveau Forgejo v10 vers la version actuelle (v15). Deux étapes, toutes deux prises en charge.
• Sur Gitea v1.23 ou plus récent : il n'existe aucun chemin direct officiellement pris en charge. Vous choisissez entre une rétrogradation SQL/schéma, des scripts de migration communautaires, une migration dépôt/API, ou une migration de préparation sur serveur neuf utilisant l'une de ces méthodes. Chacune comporte un compromis de perte de données différent.
• Sauvegardez votre répertoire de données et votre base de données avant de toucher à quoi que ce soit. Chaque chemin ci-dessous suppose que vous disposez d'une sauvegarde restaurable. Les chemins non pris en charge le supposent deux fois plus.
• Certaines choses nécessitent toujours une attention post-migration : prévoyez de recréer ou d'auditer les Personal Access Tokens, de réenregistrer les runners Actions, et de supprimer et reconstruire l'index de recherche Bleve. Prévoyez ces étapes quel que soit le chemin.
• Migrer n'est pas obligatoire. Gitea est activement maintenu. La décision de « rester sur Gitea » se tient si le risque de migration l'emporte sur le bénéfice pour votre situation.

Hors de propos ici : migrer de Gogs, GitHub ou GitLab vers Forgejo, et configurer Forgejo Actions de zéro.

Prérequis / ce dont vous aurez besoin

Avant d'exécuter la moindre commande, confirmez que vous disposez d'une sauvegarde complète et restaurable de deux éléments : votre répertoire de données Gitea (/var/lib/gitea sur une installation native par défaut) et votre base de données. Si votre base de données est SQLite, ce fichier se trouve dans le répertoire de données ; si c'est PostgreSQL ou MySQL, exportez-la séparément avec pg_dump ou mysqldump. Une migration sans sauvegarde vérifiée n'est pas une migration, c'est un pari.

Vous aurez aussi besoin de :

• Votre version actuelle de Gitea. Exécutez gitea --version (ou docker exec <container> gitea --version). Ce numéro détermine tout votre parcours.
• Votre type de base de données : SQLite, PostgreSQL, ou MySQL. Certains contournements sont spécifiques à la base de données.
• Accès root ou sudo sur le serveur.
• La conscience que le chemin pris en charge installe Forgejo v10.0 comme étape intermédiaire. Forgejo v10.0 est en EOL depuis le 16 avril 2025. Vous ne l'installez que le temps de la migration et vous en sortez immédiatement par une mise à niveau.

Pourquoi le chemin de mise à niveau direct s'est cassé

En décembre 2024, le projet Forgejo a publié une déclaration de compatibilité qui a tracé une ligne claire : « Les futures versions de Forgejo ne prendront pas en charge les mises à niveau depuis des instances Gitea exécutant la version v1.23 ou supérieure. » Cette phrase résume tout le problème en une ligne.

Quand Forgejo a fait scission de Gitea début 2024, les deux bases de code ont continué à diverger, et les schémas de base de données se sont éloignés l'un de l'autre. Forgejo a maintenu une fenêtre de compatibilité pour que les opérateurs Gitea existants puissent basculer, mais cette fenêtre avait une fin. Forgejo v10.0, sorti le 16 janvier 2025, était "the last version to allow a transparent upgrade from Gitea v1.22 or lower." Toute version plus récente que v10.0 ne lira pas directement une base de données Gitea.

C'est le calendrier qui piège les gens. Gitea v1.23 est sorti fin 2024, et le la version actuelle de Gitea en juin 2026 est v1.26.4. Si vous avez maintenu votre instance Gitea raisonnablement à jour, vous avez déjà franchi le seuil et les tutoriels standards ne décrivent plus votre situation.

À retenir : le chemin direct pris en charge plafonne à Gitea v1.22. Tout ce qui est plus récent nécessite une étape supplémentaire.

Trouvez votre chemin de migration selon la version de Gitea

Exécutez gitea --version, trouvez votre ligne, et suivez le chemin indiqué dans la troisième colonne. Tout le reste de ce guide détaille ces lignes.

Les déclarations de compatibilité de version proviennent directement de annonce officielle de compatibilité de Forgejo : Gitea jusqu'à v1.21 peut migrer vers Forgejo v7.0 à v10.0, et Gitea v1.22 peut migrer vers Forgejo v8.0 à v10.0. Les deux plafonnent à v10.0 comme dernière cible directe prise en charge.

Sous la question de version se trouvent trois stratégies de migration, et il est utile de les voir avant les étapes détaillées :

• Sur place, même serveur. Remplacez le binaire ou l'image de conteneur sur la machine existante. Effort minimal quand votre version le permet ; nécessite l'étape intermédiaire v10.0.
• Préparation sur serveur neuf. Provisionnez un nouveau serveur et utilisez-le comme cible sûre pour la méthode de migration correspondant à votre version de Gitea. Cela protège la machine Gitea d'origine et facilite le retour en arrière, mais cela ne contourne pas le problème de schéma de base de données de Gitea 1.23+.
• Migration dépôt/API. Utilisez les outils de migration de Forgejo pour récupérer les dépôts depuis l'ancienne instance Gitea. L'historique git est la partie fiable ; les métadonnées comme les issues, les PR, les labels, les releases, les données de wiki et les commentaires doivent être traitées comme relevant du meilleur effort et vérifiées dépôt par dépôt.

Le chemin pris en charge : Gitea v1.22 ou antérieur

Si vous êtes sur Gitea v1.22 ou antérieur, le documentation officielle de migration décrivent un chemin en deux étapes : migrer vers Forgejo v10.0.x, puis mettre à niveau Forgejo v10 vers la version actuelle. La première étape est un remplacement direct car Forgejo v10.x lit une base de données Gitea v1.22 ; la seconde étape est une mise à niveau Forgejo normale.

Il existe deux façons de procéder selon la manière dont Gitea fonctionne sur votre serveur. Choisissez celle qui correspond à votre configuration existante. Si Gitea fonctionne comme un service système, utilisez le chemin natif. Si Gitea fonctionne dans un conteneur, utilisez le chemin Docker. Forgejo v10.x agit comme un remplacement direct de Gitea v1.22.x.

Chemin natif (systemd)

Sauvegardez d'abord. Installez ensuite Forgejo v10.0.x en utilisant le paquet de votre distribution ou le binaire de release épinglé à v10.0. Arrêtez Gitea avant de copier quoi que ce soit. Un service en cours d'exécution qui écrit dans son répertoire de données pendant la copie corrompra la copie.

# Stop the running Gitea service before touching its data
systemctl stop gitea

Copiez la configuration et le répertoire de données vers les emplacements de Forgejo, puis corrigez la propriété. Le fichier de configuration doit être lisible par le groupe forgejo ; les données doivent appartenir à l'utilisateur forgejo.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

Démarrez Forgejo et activez-le au démarrage.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

Avant de quitter la v10.0 par mise à niveau, videz les files d'attente pour qu'aucun travail en cours ne soit perdu pendant le saut de version.

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

Mettez maintenant à niveau Forgejo v10.0.x vers la version actuelle en remplaçant le binaire par v15 et en redémarrant le service, en suivant le Guide de mise à niveau de Forgejo. Après les deux étapes, exécutez le doctor pour vérifier la base de données et corriger ce qu'il peut.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

Lisez /tmp/doctor.log avant d'appliquer toute correction automatique. Utilisez --fix seulement lorsque la sortie du doctor identifie une réparation spécifique que vous comprenez ou lorsque vous suivez un chemin de dépannage officiel.

Si le doctor ne signale aucune erreur critique et que l'interface web liste vos dépôts, la première migration est terminée.

Chemin Docker / conteneur

Si Gitea fonctionnait en conteneur, faites tourner Forgejo de la même façon. Utilisez l'image Forgejo v10.x comme remplacement direct de votre image Gitea v1.22.x, en la pointant vers le même volume de données et la même base de données. Confirmez d'abord que votre version de Docker est au moins 20.10.6. Les versions plus anciennes produisent un comportement indéfini avec les conteneurs Forgejo.

Le détail propre aux conteneurs qui piège les gens : les variables d'environnement. Forgejo conserve le préfixe GITEA_ pour la compatibilité, mais la documentation recommande de passer les deux préfixes afin que votre configuration survive à une future version de Forgejo qui abandonnerait les anciens noms.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

Pour les conteneurs rootless, les données doivent appartenir à l'utilisateur 1000 et au groupe 1000, correspondant à l'utilisateur d'exécution de l'image rootless. Une fois le conteneur démarré en v10.x, exécutez la même forgejo doctor check --all depuis l'intérieur du conteneur, puis mettez à niveau le tag d'image vers la version actuelle v15 et redémarrez.

Si vous êtes sur Gitea v1.23 ou plus récent

C'est ici que les guides standards s'arrêtent et où se trouvent réellement la plupart des installations actuelles. Il n'existe aucun chemin direct officiellement pris en charge depuis Gitea v1.23+, donc chaque option ci-dessous provient soit de la communauté, soit implique une perte de données. Avant d'en exécuter une, faites une sauvegarde complète de votre répertoire de données et de votre base de données, et confirmez que vous pouvez la restaurer. Ces approches modifient les données de production ; la sauvegarde est votre seul moyen d'annuler.

Les trois options diffèrent par le risque et par ce qu'elles préservent. Choisissez celle dont vous pouvez accepter le compromis.

Option A : rétrogradation du schéma SQL / patch de version

Le contournement le plus étroit rétrograde la version du schéma de base de données pour que Forgejo v10 la traite comme une base de données v1.22.

Remarque : ne considérez pas la mise à jour de version comme une rétrogradation complète en soi. La version de migration enregistrée et le schéma réel doivent correspondre. Sur Gitea 1.23.x, testez d'abord la rétrogradation complète sur une copie et comparez le schéma avant d'y pointer Forgejo.

Un mainteneur de Forgejo a décrit le SQL dans Ticket Codeberg #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

Après cela, vous suivez le chemin pris en charge comme si vous étiez en v1.22. La mise en garde essentielle : le mainteneur n'a confirmé cela que pour Gitea v1.23.1 spécifiquement, pas pour l'ensemble de v1.23.x. Le numéro de version du schéma est exact ; appliquer la mauvaise valeur cible à la mauvaise version de Gitea peut laisser la base de données dans un état qu'aucune migration ne peut récupérer. Ceci concerne PostgreSQL/MySQL, ce n'est pas officiellement pris en charge, et ce n'est pas testé comme procédure générale.

Astuce pro : définir directement version=305 saute la migration 304→305, qui a changé la façon dont les secrets TOTP sont encodés. Ticket Codeberg #8210 documente que cela corrompt l'authentification à deux facteurs pour les utilisateurs concernés. Le correctif consiste à fixer la version à 304, laisser la migration s'exécuter, ou vider les lignes de la table two_factor pour que les utilisateurs se réenrôlent. Ne sautez pas cette étape si un compte utilise le TOTP.

Option B : scripts de rétrogradation SQL séquentiels (Gitea 1.24-1.25.2)

Pour les versions comprises entre 1.24 et 1.25.2, un simple patch de version ne suffit pas : le schéma est passé par plusieurs états intermédiaires. Les scripts communautaires sur xlrl/prepare-gitea-migration-to-forgejo font revenir le schéma en arrière à travers les versions intermédiaires jusqu'à v1.22, après quoi vous empruntez le chemin pris en charge. Ces scripts sont un travail communautaire, pas une procédure faisant autorité, et ils ciblent SQLite comme cas principal. Exécutez-les uniquement sur une base de données que vous avez déjà sauvegardée.

Option C : migration API dépôt par dépôt (Gitea 1.26+ ou toute version)

Le chemin dépôt/API préserve les données Git de la manière la plus fiable. Selon la source, les permissions et la méthode de migration, des métadonnées optionnelles telles que les issues, les pull requests, les labels, les jalons, les releases, les données de wiki et les commentaires peuvent aussi être disponibles, mais traitez-les comme relevant du meilleur effort et vérifiez-les dépôt par dépôt. Pour une archive de code seul, c'est généralement suffisant ; pour un serveur où le traqueur d'issues constitue la mémoire de l'équipe, testez le transfert des métadonnées avant de vous engager sur ce chemin.

Deux outils expérimentaux tentent des migrations plus complètes pour 1.23+ mais présentent leurs propres lacunes. pacnpal/gitea2forgejo (GitHub) effectue un dump complet plus une synchronisation API et nécessite une SECRET_KEY correspondante pour que les champs chiffrés soient transférés, mais elle ne déplace pas les Personal Access Tokens, les runners Actions, les URL de rappel des webhooks ni la 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) est un outil expérimental basé sur Podman qui transfère les utilisateurs, les clés, les organisations, les dépôts, les issues, les PR, les releases et les mirrors, mais pas les tokens 2FA, les données d'exécution Actions ni les manifestes de paquets OCI orphelins. Considérez les deux comme expérimentaux et vérifiez le résultat par rapport à la matrice de transfert ci-dessous.

À retenir : il n'existe aucun chemin direct officiellement pris en charge depuis Gitea 1.23+. Choisissez l'option dont vous pouvez accepter le compromis de perte de données, et sauvegardez avant de commencer.

Migrer sur un serveur neuf est plus sûr, mais cela ne contourne pas le seuil de version

Un serveur neuf est l'endroit le plus sûr pour préparer et vérifier la migration, mais ce n'est pas un chemin de compatibilité de schéma distinct. Si votre source est Gitea v1.22 ou antérieur, installez d'abord Forgejo v10.0.x sur la cible, restaurez ou copiez-y les données Gitea, laissez Forgejo exécuter les migrations de base de données prises en charge, puis mettez à niveau cette instance Forgejo v10 vers la version Forgejo actuelle.

Si votre source est Gitea v1.23 ou plus récent, ne restaurez pas la base de données Gitea directement dans le Forgejo actuel en espérant qu'il démarre. Vous avez toujours besoin de l'une des approches non prises en charge 1.23+ ci-dessus : une rétrogradation ou un retour SQL par étapes, un outil de migration communautaire, ou une migration dépôt/API. Le serveur neuf réduit le risque lié au retour en arrière car la machine Gitea d'origine reste intacte ; il ne supprime pas le besoin de gérer l'incompatibilité de version de base de données.

C'est là que Le Forgejo en un clic de Cloudzy peut aider : utilisez-la comme instance cible propre, puis exécutez la méthode de migration correspondant à votre version de Gitea. L'image du marketplace de Cloudzy vous donne une cible Forgejo prête à l'emploi sur notre VPS haute performance, afin que vous puissiez vous concentrer sur les étapes de restauration, de vérification et de bascule plutôt que sur l'installation initiale. Le plan de migration dépend toujours du fait que vous soyez avant ou après le seuil de Gitea 1.22.

Ce qui se transfère et ce que vous devez refaire

Certaines de vos données se déplacent automatiquement, d'autres ne se déplacent que si une condition est remplie, et d'autres ne se déplacent jamais et doivent être recréées à la main. Savoir laquelle est laquelle avant de commencer fait la différence entre une bascule propre et une semaine d'utilisateurs perdus.

Quatre éléments frappent le plus durement car ils cassent silencieusement ou affectent tous les utilisateurs, il faut donc les traiter délibérément : les utilisateurs doivent recréer ou auditer leurs Personal Access Tokens, vous devez réenregistrer vos runners Actions contre le nouveau nom d'hôte, vous devez supprimer l'index de recherche Bleve pour que Forgejo le reconstruise proprement, et vous devez réécrire toute uses: les références courtes dans vos workflows Actions par des URL GitHub complètes, car Forgejo et Gitea récupèrent les actions depuis des mirrors distincts et une référence relative se résout au mauvais endroit.

Astuce pro : si vous faites tourner Gitea et Forgejo en parallèle pendant la migration et que les deux pointent vers la même instance Redis, changez Forgejo pour utiliser la base Redis db=1 avant de commencer. Les deux utilisent par défaut db=0, et s'ils la partagent, Gitea consomme les événements de migration de Forgejo et détruit la file d'attente de migration. (blog.mei-home.net documents this exact failure.)

À retenir : les Personal Access Tokens, les runners Actions, les clés de déploiement par dépôt, et l'index de recherche Bleve sont toujours manuels. Planifiez-les comme des tâches de migration, pas comme des réflexions après coup.

Vérifiez que la migration a réussi

Commencez par le doctor, puis vérifiez les chiffres, puis testez ce que les utilisateurs font réellement. Le doctor détecte les problèmes au niveau de la base de données ; les vérifications manuelles détectent les problèmes de perte de données et d'accès que le doctor ne peut pas voir.

1. Exécutez forgejo doctor check --all --log-file /tmp/doctor.log, puis lisez le journal avant d'apporter des modifications. Utilisez --fix seulement pour une réparation spécifique que vous comprenez.
2. Confirmez que le nombre de dépôts, le nombre d'issues et de PR, ainsi que le nombre d'objets LFS et leur taille totale correspondent tous à vos chiffres d'avant migration. Un écart ici signifie que quelque chose n'est pas passé.
3. Testez un push et un pull SSH. Si les clients rencontrent une incompatibilité de clé d'hôte, vous n'avez pas copié /etc/ssh/ssh_host_* vers le nouveau serveur.
4. Connectez-vous et confirmez que la 2FA fonctionne pour un compte qui l'utilise. Si le TOTP est cassé, consultez la mise en garde de l'Option A ci-dessus.
5. Régénérez les Personal Access Tokens, réenregistrez les runners Actions, et exécutez un workflow de test.

Quelques symptômes post-migration ont des causes connues. Un favicon ou un logo manquant signifie que vos ressources de marque sont encore dans public/assets/img/ au lieu de custom/, où Forgejo les attend désormais. Des erreurs 404 sur les routes de paquets indiquent des chemins de stockage mal configurés. Les Actions qui échouent avec « repository not found » correspondent au uses: problème de mirror. Passez à des URL complètes. Une page blanche ou une erreur 500 après connexion sur une base de données SQLite signifie que vous êtes en dessous du minimum, ce que le documentation de mise à niveau a fixé cela à Forgejo v1.19.3-0.

Quand il est judicieux de rester sur Gitea

Migrer est un choix, pas une obligation. Si vous avez déjà franchi le seuil et que la complexité de la migration l'emporte sur le bénéfice de gouvernance ou de fonctionnalités pour votre situation, rester sur Gitea est un choix légitime. Gitea est activement maintenu (plusieurs versions par mois, actuellement en v1.26.4), et CommitGo propose des options commerciales incluant Gitea Enterprise, Gitea Cloud, et la certification SOC 2 Type 2 pour les équipes qui en ont besoin.

Il y a aussi la préoccupation de l'étape intermédiaire EOL à peser honnêtement. Le chemin direct pris en charge exige d'installer brièvement Forgejo v10.0, qui est en EOL depuis avril 2025. C'est acceptable en tant qu'étape de migration transitoire dont on sort immédiatement par une mise à niveau, mais certains opérateurs s'y opposeront pour des raisons de politique. Pour eux, une migration dépôt/API vers une instance Forgejo neuve peut éviter entièrement l'étape EOL, tandis que la préparation sur serveur neuf dépend toujours de la méthode de migration choisie.

Si votre raison de migrer est l'activité de développement, les données confirment que Forgejo est le projet le plus actif : une analyse de honeypot.net a comptabilisé 3 039 commits Forgejo contre 1 228 commits Gitea entre juillet 2024 et mai 2025, et 232 contributeurs Forgejo contre 153 pour Gitea sur l'année se terminant en mai 2025. C'est un signal parmi d'autres ; pesez-le face à votre risque de migration plutôt que de le considérer comme décisif.

À retenir : migrer n'est pas obligatoire. La décision est une préférence de gouvernance et d'activité pesée contre le risque de migration, et les deux choix sont défendables.

Choisissez votre chemin et sauvegardez d'abord

Votre chemin de migration se résume à un seul chiffre : votre version de Gitea. En v1.22 ou antérieur, vous empruntez le chemin en deux étapes pris en charge via Forgejo v10. En v1.23 ou plus récent, vous choisissez un contournement selon la perte de données que vous pouvez accepter : rétrogradation SQL/schéma, scripts communautaires, migration dépôt/API, ou migration de préparation sur serveur neuf. Quel que soit le chemin emprunté, sauvegardez d'abord votre répertoire de données et votre base de données, exécutez forgejo doctor après, et confirmez que vos nombres de dépôts, d'issues et d'objets LFS correspondent à ce avec quoi vous avez commencé.

Identifiez votre version, effectuez la sauvegarde, et suivez la ligne correspondante. Le chemin est plus complexe que ce que promettaient les anciens tutoriels, mais il est bien défini une fois que vous savez où vous vous situez par rapport au seuil de version.

Foire aux questions

Puis-je effectuer une mise à niveau directe de Gitea vers Forgejo ?

Oui, si vous faites tourner Gitea v1.22 ou antérieur : mettez à niveau directement vers Forgejo v10.0, puis mettez à niveau Forgejo v10 vers la version actuelle. Non, si vous faites tourner Gitea v1.23 ou plus récent. Forgejo v10.0 était la dernière version prenant en charge une mise à niveau directe et transparente, donc les versions de Gitea plus récentes ont besoin d'un contournement à la place.

Quelle version de Gitea est compatible avec Forgejo ?

Gitea v1.22 et antérieur disposent d'un chemin de mise à niveau direct pris en charge vers Forgejo (jusqu'à Forgejo v10.0, puis vers la version actuelle). Gitea v1.23 et plus récent n'ont aucun chemin direct officiellement pris en charge, car Forgejo a cessé de prendre en charge les mises à niveau transparentes depuis Gitea v1.23+ à partir des versions postérieures à v10.0.

Puis-je migrer de Gitea 1.26 vers Forgejo ?

Oui, mais pas via une mise à niveau directe prise en charge. Vos options sont une migration dépôt/API, où l'historique git est la partie fiable et où les métadonnées doivent être testées dépôt par dépôt, un script de migration expérimental, ou une migration de préparation sur serveur neuf utilisant l'une des méthodes non prises en charge 1.23+ ci-dessus. Il n'existe aucun chemin sur place officiellement pris en charge depuis Gitea 1.26.

Mes Personal Access Tokens sont-ils transférés ?

Prévoyez de recréer ou de faire pivoter les Personal Access Tokens après la migration. Certains chemins de migration ne les préservent pas, et même lorsque les tokens restent présents, les utilisateurs devraient auditer leurs scopes avant de s'y fier à nouveau. Tout script ou intégration utilisant d'anciens tokens doit être testé et mis à jour après la bascule.

Mes workflows Gitea Actions fonctionnent-ils dans Forgejo ?

En grande partie, avec deux corrections nécessaires. Le workflow uses: les références courtes cassent parce que Forgejo et Gitea récupèrent les actions depuis des mirrors distincts. Remplacez-les par des URL GitHub complètes (par exemple, uses: https://github.com/sammcj/dotenv-output-action@main). Vous devez aussi réenregistrer vos runners Actions, car leurs tokens d'enregistrement sont liés à l'ancien nom d'hôte.

Qu'en est-il de la migration de Gogs vers Forgejo ?

Il s'agit d'une migration différente avec un chemin différent, hors de propos ici. Ce guide couvre spécifiquement Gitea vers Forgejo ; pour une source Gogs, consultez la documentation officielle de migration de Forgejo pour la procédure spécifique à Gogs.