How to migrate Gitea to ForgeJo

:uk: English version - Gitea to ForgeJo migration on Yunohost

On May 4th 2024, we switched from Gitea to FogeJo on our YunoHost server
This howto describes how we have migrated our Gitea instance to ForgeJo. It may not cover all cases.

:fr: French version below :arrow_down:

First step

Create a temporary domain for the migration process
Install ForgeJo on the temporary domain

Gitea dump

In the Gitea user folder (/opt/yunohost/gitea) we have to dump gitea data with the command

sudo -u gitea ./gitea dump -d postgres -f gitea-dump.zip

-d postgres allows to save the database to postgresql format because that is what is used by ForgeJo

Unzip the file gitea-dump.zip in some temporary working folder

Import repositories and data into ForgeJo

Copy the folder ./repos to /home/yunohost.app/forgejo/repositories.
Copy the folder ./data to /home/yunohost.app/forgejo/data/.

Set ownership on folder /home/yunohost.app/forgejo to the forgejo user.

sudo chown -R forgejo: /home/yunohost.app/forgejo

Import database dump into ForgeJo

You can find the ForgeJo DB password in the file /var/www/forgejo/custom/conf/app.ini

First all existing data of the ForgeJo database has to be deleted

psql --user forgejo -d forgejo -c "DROP OWNED BY forgejo;"

Then we import the Gitea dump

psql --user forgejo -d forgejo < gitea-db.sql

Finally we need to recreate the yunohost_api user that was lost when we deleted all the data because it does not exists on Gitea.
The esieast way to do that is to force an upgrade of the ForgeJo app, because that user is created if it does not exists by the upgrade script.

yunohost app upgrade --force forgejo

Test ForgeJo

Test that everything is working correctly on ForgeJo, comparing with Gitea to be sure everything has been correctly migrated

Switch domains

Change the domain of Gitea to use the temporary domain
Change the domain of ForgeJo to use the original domain used by Gitea

Delete Gitea

Once we have ensured that everything is correctly working Gitea can be uninstalled.
If unsure, Gitea can be kept installed on the temporary domain as long as desired.

Things to do on the client side

It happens that SSH connections URLs are not the same with ForgeJo.
gitea@ becomes forgejo@.

So, on the client side, if ssh is used the remote URLs have to be updated. This can be done using the command

git remote set-url origin $(git remote get-url origin | sed -e "s/gitea@git.distrilab.fr/forgejo@git.distrilab.fr/")

The previous command assumes that there is only one remote, that is named origin. To verify that it is the case all remotes can be listed with the command

git remote -v

We are not using HTTPS on the client side. So we have not checked if anything has to be done in that case.

Thanks

Kudos to @mckmonster who has done the bulk of the migration. I only helped to fix a couple of issues and to translate the procedure in english

:fr: Version Française - Migration de Gitea vers ForgeJo dans Yunohost

Ce howto décrit comment nous avons migré notre instance Gite vers ForgeJo. Il y a peut être des cas spécifiques qui ne sont pas couvert par cette procédure.

Le 04 Mai 2024, on a fait le switch de Gitea vers FogeJo sur notre serveur YunoHost

First step

Créer un domaine temporaire qui sera utilisé pendant la migration.
Installer ForgeJo sur le nom de domaine temporaire

Dump de Gitea

Dans le répertoire du user de Gitea (/opt/yunohost/gitea), il faut dumper gitea avec la commande

sudo -u gitea ./gitea dump -d postgres -f gitea-dump.zip

-d postgres permet de sauver la database au format postgresql car ForgeJo est sous Postgresql.

Décompresser le fichier gitea-dump.zip dans répertoire de travail.

Import des repos et data dans ForgeJo

Copier le répertoire ./repos dans /home/yunohost.app/forgejo/repositories.
Copier le répertoire ./data dans /home/yunohost.app/forgejo/data/.
Puis remettre les droits sur le répertoire /home/yunohost.app/forgejo pour l’utilisateur forgejo.

sudo chown -R forgejo: /home/yunohost.app/forgejo

Import de la database dans ForgeJo

Vous pouvez trouver le mot de passe de la db ForgeJo dans le fichier /var/www/forgejo/custom/conf/app.ini

Il faut d’abord supprimer les infos de la database

psql --user forgejo -d forgejo -c "DROP OWNED BY forgejo;"

Puis importer la database qui provient de gitea

psql --user forgejo -d forgejo < gitea-db.sql

Et ensuite il faut recréer le user yunohost_api qu’on a perdu en supprimant toutes les donnée de la base, qui n’existe pas sur gitea et qu’on n’a donc pas récupéré en important le dump de la base gitea.
Le plus simple pour faire ça c’est de forcer une mise a jour de forgejo, ce user étant créé par le script d’upgrade si il n’existe pas.

yunohost app upgrade --force forgejo

Tests

Tester que tout fonctionne correctement sur ForgeJo, en comparant avec Gitea pour vérifier que toutes les données on bien été migrées.

Passer ForgeJo sur le nom de domaine de Gitea

Passer Gitea sur le nom de domaine temporaire.
Mettre le DNS qui était utilisé par Gitea sur ForgeJo.

Supprimer Gitea

Un fois qu’on a testé que tout est bon sur ForgeJo, on peut supprimer Gitea et le nom de domaine temporaire.
En cas de doute, Gitea peut être conservé sur le domaine temporaire aussi longtemps que souhaité.

Sur les clients

Il se trouve que les URL SSH ne sont plus les mĂŞme avec gitea
gitea@ devient forgejo@.

Si SSH est utilisé coté client il faut donc faire le remplacement dans les URL des remote pour que ça continue à fonctionner. Cela peut être fait en utilisant la commande

git remote set-url origin $(git remote get-url origin | sed -e "s/gitea@git.distrilab.fr/forgejo@git.distrilab.fr/")

La commande précédente suppose qu’il n’y a qu’un remote et qu’il s’appelle origin. Pour vérifier que c’est le cas on peut lister les remotes d’une copie locale avec la commande

git remote -v

Nous n’utilisons pas HTTPS coté client. Donc nous n’avons pas vérifié si il y a quelque chose a faire dans ce cas.

Remerciements

Merci à @mckmonster qui a fait le gros du travail. J’ai juste aidé à résoudre une paire de problèmes et à faire la traduction de la procédure en Anglais

7 Likes

Un grand merci @lab.8916100448256 ! Vais essayer à mon tour…

english version (version en français après)

I migrated today from Gitea 1.22.0~ynh1 to Forgejo 8.0.0~ynh1. I followed these instructions, which worked fine, except for the following things:

  • When importing from the dump, some user imports silently failed due to their keep_activity_private field being NULL but having the NOT NULL restriction. This caused HTTP 500 errors on some pages. I had to set a value before the migration:
    mariadb -p
    \r gitea
    UPDATE user SET keep_activity_private = true WHERE keep_activity_private IS NULL;
    
  • The forced upgrade failed because the upgrade script didn’t recreate the yunohost_api user, so I created it manually instead (based on what the Forgejo package is doing):
    systemctl restart forgejo
    source /usr/share/yunohost/helpers
    forgejo_api_user=yunohost_api
    forgejo_api_pwd=$(ynh_string_random --length=24)
    forgejo_domain=change.me.example
    ynh_app_setting_set --app=forgejo --key=forgejo_api_user --value="$forgejo_api_user"
    ynh_app_setting_set --app=forgejo --key=forgejo_api_pwd --value="$forgejo_api_pwd"
    cd /var/www/forgejo
    sudo -u forgejo ./forgejo admin user create --username "$forgejo_api_user" --password "$forgejo_api_pwd" --email "admin@$forgejo_domain" --admin --must-change-password=false
    forgejo_api_token=$(sudo -u forgejo ./forgejo admin user generate-access-token --username "$forgejo_api_user" --token-name "admin" --scopes "write:admin" --raw | tail -1)
    ynh_app_setting_set --app=forgejo --key=forgejo_api_token --value="$forgejo_api_token"
    
  • Not sure of what was the problem exactly, but I also chose to reset the theme for each user:
    sudo -u postgres psql
    \c forgejo
    UPDATE "user" SET theme = 'forgejo-auto';
    

version en français (english version before)

J’ai fait la migration de Gitea 1.22.0~ynh1 à Forgejo 8.0.0~ynh1 aujourd’hui. J’ai suivi ces instructions, qui ont bien marché, sauf pour les choses suivantes :

  • Lors de l’import du dump, certains comptes Ă©taient silencieusement ignorĂ©s Ă  cause du champ keep_activity_private valant NULL mais ayant la restriction NOT NULL. Ça causait des erreurs HTTP 500 sur certaines pages. J’ai dĂ» leur dĂ©finir une valeur avant de migrer :
    mariadb -p
    \r gitea
    UPDATE user SET keep_activity_private = true WHERE keep_activity_private IS NULL;
    
  • La mise Ă  jour forcĂ©e a Ă©chouĂ© car le script de mise Ă  jour ne recrĂ©ait pas le compte yunohost_api, donc je l’ai crĂ©Ă© manuellement Ă  la place (dĂ©rivĂ© de ce que fait le paquet de Forgejo) :
    systemctl restart forgejo
    source /usr/share/yunohost/helpers
    forgejo_api_user=yunohost_api
    forgejo_api_pwd=$(ynh_string_random --length=24)
    forgejo_domain=change.moi.example
    ynh_app_setting_set --app=forgejo --key=forgejo_api_user --value="$forgejo_api_user"
    ynh_app_setting_set --app=forgejo --key=forgejo_api_pwd --value="$forgejo_api_pwd"
    cd /var/www/forgejo
    sudo -u forgejo ./forgejo admin user create --username "$forgejo_api_user" --password "$forgejo_api_pwd" --email "admin@$forgejo_domain" --admin --must-change-password=false
    forgejo_api_token=$(sudo -u forgejo ./forgejo admin user generate-access-token --username "$forgejo_api_user" --token-name "admin" --scopes "write:admin" --raw | tail -1)
    ynh_app_setting_set --app=forgejo --key=forgejo_api_token --value="$forgejo_api_token"
    
  • Je suis pas sĂ»re de ce qu’était le problème exactement, mais j’ai aussi choisi de rĂ©initialiser le thème pour tous les comptes :
    sudo -u postgres psql
    \c forgejo
    UPDATE "user" SET theme = 'forgejo-auto';