[Forgejo Migration] Migrate GitHub issues to Forgejo

[foss-]

Part of Forgejo Migration: Migrate GitHub issues to Forgejo

Depends on https://codeberg.org/forgejo/forgejo/issues/340
Blocked by https://forum.forgefriends.org/t/about-the-friendly-forge-format-f3/681 or go-gitea/gitea#18165
Resolves #9834

[foss-]

The good news is, @organicmaps has just fully moved to Forgejo as per https://mastodon.social/@organicmaps/114233788700982882

• 54k commits
• 9.5k issues
• 4.3k pull requests
• 100k comments

Meaning whatever got stuck during the 2023 attempt to move Friendica to codeberg may no longer be an issue or they just used another database format 🤔. Call for volunteers to give the migration another go I guess 🫣

[annando]

Before we do the move, I would like to check if its possible to have got some server structure there with at least two servers with some fallback/synchronization mechanism, so that the repository will work, even when one of the servers fail. it will happen from time to time that the server isn't working totally fine. And since we are all doing it in out spare time, no one can expect that problems are fixed in minutes or even hours. So it would be great to have some fallback mechanism.

BTW: I really don't know if Forgejo can do something like that and also I'm not admin enough to even know if this is possible at all.

[tobiasd]

I'll do a test migration later today.

[MrPetovan]

@annando We already have a GitHub mirror of the addons repository, we can also keep the core GitHub repository as a read-only mirror of the ForgeJo repo.

[Art4]

Before we do the move, I would like to check if its possible to have got some server structure there with at least two servers with some fallback/synchronization mechanism, so that the repository will work, even when one of the servers fail. it will happen from time to time that the server isn't working totally fine. And since we are all doing it in out spare time, no one can expect that problems are fixed in minutes or even hours. So it would be great to have some fallback mechanism.

Very good point. The reliability is very important and as we can see with the addon repository sometimes the server no longer responds. What do you think about switching to codeberg instead of own servers?

[MrPetovan]

I don't think we should switch from a third-party platform to another third-party platform, but I wouldn't mind having several read-only mirrors on popular platforms like GitHub or Codeberg.

[marcusxss]

Very happy to see an issue for this!

If needed I'd gladly try to help out with the migration. Hopefully it would inspire other open source projects to do the same, such as weblate, who I notice have linked to this issue.

I'm already running my own forgejo instance, though it's just for personal use so I haven't had much need to really dive into its features yet. Codeberg I've yet to try out but I'd use that as a mirror personally, or secondarily GitLab. GitLab uses a different CI syntax than GitHub though.

[annando]

My big problem with the move is stability. We all have got our daytime jobs and we have got other stuff that we do in our spare time as well. We see it with the pipeline and the addon repository that it crashes from time to time. And then it can take some hours until the pages run again. It is impossible for us to guarantee a 24/7 availability, unless we would be able to pay someone for this - which we can't.

The only solution that I see is some kind of load balancer combined with several git instances (Ideally run by different people) that are synchronised. And I really don't know how how to do this. This is way out of my abilities.

[marcusxss]

Self hosted

It sounds like either the server isn't powerful enough or it's an issue of configuration?? Or maybe the software is unstable and it needs to have some sort of "self healing" set up? If it self healing, that sounds a bit like Kubernetes to me, but I'm not that familiar with Kubernetes personally. I've used Docker and Podman a little - but not yet Kubernetes. Podman can start kubernetes clusters, though. But kubernetes would be more taxing for the server, and not knowing the server I don't know if it can handle it?

Alternatively I'm wondering if it could be possible to have the pipeline/runners somewhere else, and then only have the repo, issues, pull requests and such to deal with on this server.

As for paying for server costs, if there was something similar to Patreon (but something that takes a smaller cut), perhaps some of the thousands of users would be willing to help pay for hosting the code. I remember someone asked about donating to Friendica not that long ago, so at least some people seem interested in it.

Codeberg

Otherwise perhaps Codeberg is the way to go after all, as @Art4 suggested.
IMO anything is better than GitHub, and it would be unfortunate if the lack of a perfect solution should stand in the way of something that isn't perfect but still better.

And Codeberg is a good solution IMO. It would be hosted in Europe, and specifically Germany, where the most devs are located, where friendi.ca is also hosted. It would also make everyone much more familiar with Forgejo since it's mostly Forgejo under the hood, in case we wanted a switch to Forgejo in the future, and then Codeberg could become the mirror.

Edit: Oh, and I would also gladly help in migrating to Codeberg as well, in case that's wanted.

[marcusxss]

Turns out there are various third party runners for GitHub flavoured CI:
https://github.com/neysofu/awesome-github-actions-runners
...but it would come with a cost, perhaps because Microsoft wants the code on GitHub so badly, so they can train their LLM on it that they're willing to lose some money on it. And also, in general, so they can maintain control of the open source community.
Alternatively maybe the pipeline could run on Codeberg even if the code lives on our own Forgejo.

The reason I was thinking it might be relevant to run the CI elsewhere is since I imagine it's the most resource hungry component, but then I remembered that the CI is already running on friendi.ca. I'm unsure if it's the full CI, and GitHub runs the same, or if it's only part of the CI running on friendi.ca?

More on importing issues (and other data)

I think either Codeberg or Forgejo should be able to import the issues with a GitHub Access Token. I've created an issue to Forgejo for more detailed documentation, as I'm unsure of whether any token can do so for a public repo, or if it needs to be a token for a user/organisation with some relation to the repo, like being a member, owner of it or something. I assume a read only token is enough. UPDATE: See edit below.

If it's a fine-grained token rather than a classic one, from looking at GitHubs documentation I think these are the needed permissions:

Migrating what	Read access required for
Issues	Issues
Pull requests	Pull requests
Milestones	Issues
Labels	Issues
Releases	Contents

Edit: It turns out that for a public repo and issues, at least, the personal access token can be from an account that's not a member of the repo/organization.

[marcusxss]

A (mostly) inspiring case:
Zig just moved to Codeberg (Forgejo-based).

• https://ziglang.org/news/migrating-from-github-to-codeberg/
• https://www.theregister.com/2025/12/02/zig_quits_github_microsoft_ai_obsession/
• https://codeberg.org/ziglang/zig (Codeberg is currently experiencing a DDOS, though)

...but they decided not to migrate their 30000 issues (about 3000 open ones) currently:

In the end, we opted for a simple strategy, sidestepping GitHub’s aggressive vendor lock-in: leave the existing issues open and unmigrated, but start counting issues at 30000 on Codeberg so that all issue numbers remain unambiguous. Let us please consider the GitHub issues that remain open as metaphorically “copy-on-write”. Please leave all your existing GitHub issues and pull requests alone. No need to move your stuff over to Codeberg unless you need to make edits, additional comments, or rebase. We’re still going to look at the already open pull requests and issues; don’t worry.

Not sure how issues migration was blocked specifically, though. Maybe they have too many, or comments or something aren't carried over? Not sure if one can only migrate open issues somehow?
But their approach would be another way to do so:
Leave old issues and PRs here, maybe stop the creation of new ones here (if possible), instead referring to creating them on the new one. Then at some point later it could be archived here as well?

That said, git.friendi.ca is currently returning "bad gateway" when nginx tries to connect to, I assume, forgejo? But I imagine it's fixable and that it could be reduced in frequency and I would gladly help investigate it. I wonder if the server just isn't powerful enough for the peak demands on it. Or is it forgejo or specifically the CI part that's unstable?

[annando]

@mfxa git.friendi.ca runs on an own machine using Gitea.

[marcusxss]

Is there anything I can do to help with/accelerate this migration?
I've been planning to make this my highest priority after the recent release, but hadn't gotten around to following up.
Also I'll help if the target is Codeberg or Source Hut or something instead as well. I would just like to stop supporting closed source Microsoft GitHub.