Moving from GitHub to Codeberg, for lazy people
I’ve just started to migrate some repositories from GitHub to Codeberg. I’ve wanted to do this for a long time but have stalled on it because I perceived Codeberg as not being ready and the migration process as being a lot of (boring) work.
It turns out that is only partially true and wildly depends on your project. If you’re in a similar position as me, hopefully these notes serve as motivation and starting point. These solutions are not what I might stick around with long-term, but aimed at what I think is easiest to get started with when migrating from GitHub.
First, there’s the migration of issues, pull requests and releases along with their artifacts. This is actually the easiest part since Codeberg offers repository import from GitHub that just works, and all these features have a UI nearly identical to GitHub’s. The import preserves issue numbers, labels, authorship. The user experience is very much a step above the extremely awkward hacks that people use to import from other issue trackers into GitHub.
If you’re using GitHub Pages you can use codeberg.page. There’s a warning about it not offering any uptime SLO, but I haven’t noticed any downtime at all, and for now it’s fine. You push your HTML to a branch, very much like the old GitHub Pages.
The by far nastiest part is CI. GitHub has done an excellent job luring people in with free macOS runners and infinite capacity for public repos 1. You will have to give up on both of those things. I recommend looking into cross-compilation for your programming language, and to self-host a runner for Forgejo Actions, to solve those problems respectively.
Why Forgejo
Actions and not Woodpecker CI, isn’t Woodpecker on Codeberg more
stable? Yes, absolutely, in fact the
documentation for Forgejo Actions on Codeberg is out of date right
now, but Forgejo Actions will just feel way more familiar coming
from GitHub Actions. The UI and YAML syntax is almost identical, and the
existing actions ecosystem mostly works as-is on Codeberg. For example,
where my GitHub Actions workflow would say
uses: dtolnay/rust-toolchain, my Forgejo Actions workflow
would just change to
uses: https://github.com/dtolnay/rust-toolchain.
If you absolutely need macOS runners I’d recommend sticking with GitHub Actions on the GitHub repository, mirroring all commits from Codeberg to GitHub and using Forgejo Actions to poll the GitHub API and sync the CI status back to Codeberg. I haven’t tried this one yet, but I have tried some other CI providers offering macOS builds and I don’t think they’re easier or cleaner to integrate into Codeberg than GitHub Actions.
Finally, what to do with the old repo on GitHub? I’ve just updated the README and archived the repo.
You could tell Codeberg to push new commits to GitHub, but this
allows users to still file PRs and comment on issues and commits 2. Some folks have dealt with this by
disabling issues on the GitHub repo, but that is a really destructive
action as it will 404 all issues, and pull requests cannot be disabled.
Some repos like libvirt/libvirt have written a GitHub
Action that automatically closes all pull requests.
This itself has some terrible consequences for self-hosting and the broader software ecosystem, as folks have no incentive to optimize their builds or how often they download a release tarball from your website.↩︎
You might still want to maintain a read-only mirror during a transitionary period, or to keep using GitHub pages and GitHub Actions.↩︎