this post was submitted on 02 Apr 2024
15 points (85.7% liked)

Selfhosted

40134 readers
623 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

Hi. I self-host gitea in docker and have a few repos, users, keys, etc. I installed forgejo in docker and it runs, so I stopped the container and copied /var/lib/docker/volumes/gitea_data/_data/* to /var/lib/docker/volumes/forgejo_data/_data/, but when I restart the forgejo container, forgejo doesn't show any of my repos, users, keys, etc.

My understanding was the the current version of forgejo is a drop-in replacement for gitea, so I was hoping all gitea resources were saved to its docker volume and would thus be instantly usable by forgejo. Guess not. :(

Does anyone have any experience migrating their gitea instance to forgejo?

top 21 comments
sorted by: hot top controversial new old
[–] [email protected] 7 points 7 months ago (1 children)

I recently did a bare metal migration from Gitea to Forgejo using NixOS, maybe this info is useful if you use SQLite (which I believe is the default): the SQLite database filename for Gitea is gitea.db and for Forgejo it’s forgejo.db so I had to do a rename. Before renaming I ended up with an empty Forgejo instance. Either way I hope you figure it out in the end. Good luck!

[–] [email protected] 1 points 7 months ago (1 children)
[–] [email protected] 2 points 7 months ago* (last edited 7 months ago)

Unfortunately that didn't work for me.

[–] [email protected] 5 points 7 months ago (1 children)

Why this backwards way of migrating? The recommended way to to replace the Gitea docker image with the Forgejo one and leave everything else in place. Maybe make a backup before that you can revert to in case something goes wrong though.

[–] [email protected] 4 points 7 months ago (2 children)

That's essentially what they did.

[–] [email protected] 4 points 7 months ago (1 children)

You have a very loose definition of "essentially". I can see easily see multiple ways of the OP's copy approach failing while swapping out the container in place would not.

[–] [email protected] 1 points 7 months ago (1 children)

Can you share some of them so I might have an idea what to try to do differently?

[–] [email protected] 2 points 7 months ago (1 children)

You need to share more details about your setup, but as others have already mentioned, it could be an database issue, because usually Gitea is configured to use a Postgresql database.

Also make sure you don't combine an upgrade with a migration, the Gitea and Forgejo versions need to be roughly the same. Especially around the 1.20 version there was a need to change the folder structure before upgrading.

[–] [email protected] 1 points 7 months ago

Thanks for that info. I did combine an upgrade (1.20 to 1.21) with the migrations, but I guess I lucked into it working. My problem was that the container's path to the migrated gitea volume was incorrect.

[–] [email protected] 3 points 7 months ago

That is what I did. And it didn't work.

[–] [email protected] 4 points 7 months ago (1 children)

What are you using as a database? Also, from which Gitea version to which Forgejo version did you attempt the migration?

[–] [email protected] 1 points 7 months ago

Both gitea and forgejo are using sqlite3. Gitea 1.20.0, Forgejo 1.21.

[–] [email protected] 3 points 7 months ago (1 children)

Can you see the data you copied inside the container? I’m quite sure you either don’t have the volume mounted, or the config files refers to a different folder than the gitea one did. Did your gitea container store data in sqlite as you are copying raw files rather than migrating a database?

I’d go with lxc instead of containers if you don’t fully understand docker. Overhead isn’t much different and you get a “normal server” where you can drop in forgejo to replace gitea

[–] [email protected] 2 points 7 months ago

Can you see the data you copied inside the container?

That led me to my problem! I did have the volume mounted, but the container's path was incorrect: Forgejo was recreating it's resource files as a new install because where it was looking for them, they didn't exist.

Thanks!

[–] [email protected] 2 points 7 months ago* (last edited 7 months ago) (1 children)

Why migrate from gitea to forgejo?

[–] [email protected] 0 points 7 months ago

No experience, but saw gorgeous has a guide to migrate. Their latest Blogpost states to do that ASAP coz they're going to stop keeping the drop-in 1:1 replacement to advance in their cool feature set ;)

[–] [email protected] -1 points 7 months ago* (last edited 7 months ago) (1 children)

Okay so your post inspired me to make the switch. All I had to do was switch out the image to the forgejo one. Everything worked right away. To try to make things as clean as possible, I went ahead and renamed my bind volume paths and app.ini stuff from gitea to forgejo but no matter what I tried, once I started the container, the container would create a gitea directory with a new app.ini. I even tried to run the forgejo compose on another host and the app still creates a gitea directory within the bind mount. Am I doing something wrong. I understand it’s a drop in replacement but I’m sure there’s a way to get a cleaner cut over.

compose.yml

volumes:

  • ./data:/data

Host directories

~/forgejo

  • data - forgejo - renamed for the migration - git - ssh - gitea - gets created by the app no matter what I do or what paths are set in app.ini
  • compose.yml

How do I keep forgejo from creating this gitea directory? Why doesn’t it create a forgejo directory???

Edit: gitea version was - 1.21.7 and forgejo replacement image is 1.21.7-0

[–] [email protected] 1 points 7 months ago (1 children)

I don't know if your problem is the same as mine was, but the symptom sounds the same.

The docker-compose.yaml file shown in the Forgejo documentation for docker installation shows this mount:

    volumes:
      - ./forgejo:/data

For me, Forgejo installed and created new resource files in /data and ignored the resource files gitea alread made.

I changed the volume to:

    volumes:
      - data:/var/lib/gitea

Forgejo then recognized the gitea resources.

[–] [email protected] 1 points 7 months ago

Not quiet. I was running gitea before so my mount was ./gitea:/data but since switching over to forgejo, I renamed my ./gitea directory to ./forgejo. Adjusted my compose file to have a mount of ./forgejo:/data.

Now inside of that renamed forgejo directory, there are a bunch of gitea references and even one more directory called gitea. When I migrated everything worked right away but since I wanted a cleaner transition, I renamed and switched all gitea references to forgejo but went I brought the stack back online, it went belly up.

As a troubleshooting step, I recreated my compose file and created a new empty ./forgejo on a different machine just to see what a new and fresh install would look like and the forgejo stack itself created all kinds of gitea references and gitea directory once I brought it up. So to fix my original deployment, I reverted all the references back from forgejo to gitea and everything worked again.

For fun, I went out to codeberg to look at the Dockerfile and saw that they had a bunch of gitea things within their own Dockerfile so nothing I can do for now