Submitted 3 weeks ago by witten@lemmy.world to selfhosted@lemmy.world
The time to do this was before the hard fork.
The easy way to do this is make your user(s) and use Forgejo’s migration functions. Why would you muddy this up like this? Just nuke and pave, it would take a tenth of the time and be a hell of a lot less chancy in their long term.
The best time to do was before the hard fork. The second best time was was, well, now. Also, I am the user(s) of this former Gitea instance, just in terms of who owns the repos on it. And like I said above, I didn’t want to lose all of the data that the built-in migration feature wouldn’t migrate.
I’m staying with Gitea. They’ve created the Ltd. so they can sell professional support as most businesses will want a proper invoice. I don’t see anything wrong with that. Also, ForgeJo was promising federation which is still a WIP several years later. And, the one time I’ve tried ForgeJo it shit itself when I’ve added an emoji to my username. For some reason Gitea didn’t have any problem with that.
Personally, I think it’s great to have multiple options in this space. I think we can all agree that self-hosting (or using Forgejo/Gitea on a smaller platform, e.g. Codeberg) is preferable to centralizing absolutely everything on Microsoft GitHub.
If you are not a Gitea customer, you are not being informed of security updates in a timely manner:
Gitea repeatedly makes choices that leave Gitea admins exposed to known vulnerabilities during extended periods of time. For instance Gitea spent resources to undergo a SOC2 security audit for its SaaS offering while critical vulnerabilities demanded a new release. Advance notice of security releases is for customers only.
forgejo.org/compare-to-gitea/#security
Also, ForgeJo was promising federation which is still a WIP several years later.
Oh no, it doesn’t do the big feature™. I guess it’s unusable now.
I wish people would realize that software still works and is excellent even without the various flagship features. I use Kubernetes on a single node. I know there are people who use matrix without federation and e2ee because it’s actually a really good chat app, it just struggles with the performance demands of federation, and the e2ee ux isn’t quite there yet.
If you are not a Gitea customer, you are not being informed of security updates in a timely manner
I don’t need a notification of issues, I need a notification of when there’s a new version to roll out. And that can be solved by using things like WatchTower or setting up release notifications on GitHub.
And, of course, a comparison hosted on ForgeJo’s webpage will make it out that they’re “the better choice”.
Also, ForgeJo was promising federation which is still a WIP several years later.
Oh no, it doesn’t do the big feature™. I guess it’s unusable now.
Well, that was the one big distinguishing thing between the two, back when ForgeJo was the new kid on the block. ForgeJo wanted to make it a priority to implement federation.
And I never said it’s unusable - it’s just that I, personally, don’t see any reason to switch from Gitea to ForgeJo.
Has Gitea even given any indication that they want to work on federation themselves?
Yes. But this is a lot. It may be easier to use Forgejo’s built in migration tools, to copy over repositories along with their issues and other info. You would have to rebuild the admin parts of the site, like “organizations” and user privileges. (Well if you are using oauth and mapping users from oautb groups then you don’t…). And I don’t know if it’s automated for a many, many repos. But it’s just a click click click in the gui.
I remember there was a tool, I think it was related to forgefed, that could do batch repo migrations via the cli. I can’t find it anymore though.
That would be ideal if it worked, yeah. But personally I wouldn’t want to manually recreate the bits that it didn’t support migrating. I realize everyone’s instance and situation is different.
I just spun up Forgejo and pushed up all my repos by hand because I’m lazy.
Sounds like not lazy at all. If anything more work depending on the number of repos!
I had like 10 repos and nothing of much value in the DB, so it was quick to create the repos and push them up.
I wrote a python handler to query the GItea api and either mirror from source repos that were a straight mirror, or full clone/standalone local repos. Also handled creating orgs (using the forgejo api), since I wasn’t going to do any of that by hand.
That sounds pretty nice. Did it also handle issues and comments and stuff?
I didn’t have any to move, so I didn’t allow for that. I’d assume not though.
There’s a better way
Start with the last Forgejo version to be compatible with with Gitea and then slowly upgrade Forgejo one version at a time. This should be trivial to do and can be scripted easily.
I don’t understand. How would that help switching from a Gitea 1.25.x instance?
Shoot your right
Never mind I guess. You would need to downgrade which I don’t think is possible
Literally
Forgejo past 10.0.x is not compatible with Gitea’s database schema. Have you tried it?
Thanks for writing this up. I went through the same migration last year and can confirm — it is not as smooth as “just swap the binary” anymore since the hard fork.
A few extra tips that saved me headaches:
pg_dump if you are on Postgres, or just copy the SQLite file.Overall though, Forgejo has been great post-migration. More responsive to community issues and the federation work they are doing is exciting.
eleijeep@piefed.social 3 weeks ago
Using an LLM to do a database migration is like asking your neighbour’s kid to file your taxes.
witten@lemmy.world 3 weeks ago
Lol that’s a good idea… I hate doing taxes!
30p87@feddit.org 2 weeks ago
And you love going to jail for gross tax fraud?