Github has always been a very enticing code forge. You get a lot of things for free. Code hosting, decent issue management, Gists, Pages, CI etc. Of course, all of these things are also there to make the service more sticky. They’ve moved the baseline expectations of the services a forge should provide for free so far up it’s hard for entities without VC capital or Microsoft’s war chest to provide an enticing, competing offer. Embrace, extend, extinguish, in its own way.
Up to now I was happy to stay on Github, but then came Copilot. At first it was just an annoying banner or feature here or there. Most of these I could make disappear by changing a setting or adding a simple line in uBlock. But the push for Copilot has gotten worse and more invasive over the past six months. Clearly, Microsoft needs the line to go up to justify the billions its burning on AI and its investments in OpenAI. It’s now gotten to the point where it’s trying to make me use Copilot when creating issues and is actively getting in my way.
So, it’s time to GTFO.
But where to go? For my own projects, I’ve decided on Codeberg. Microsoft’s push for Copilot has managed to achieve what Github never could: make me pay for a forge. I am a paying, voting member of Codeberg e.V now. Having an independent platform that’s not subject to the new fascist regime in the US is more important than ever. I considered sr.ht but I abhor the e-mail based git flow, so that’s out.
Migrating repositories
Forgejo, the forge that Codeberg runs, has very good import support for Github. It’ll transfer issues etc. This works well enough that for projects where Codeberg is a suitable home I doubt you’ll have any problems migrating.
The bigger issue is CI. Codeberg does not provide CI by default, though you can request access to a hosted Woodpecker instance but it comes with a number of limitations. There is also Actions support, but it’s wobbly. You’ll probably need to use some other CI service. Take a look at Circle CI or build.sr.ht. Cirrus is really nice too, but they unfortunately only integrate with Github.
Codeberg Pages is a thing, but it’s not as reliable and available as Github Pages. I don’t consider that a problem. If you need high availability and reliability for a project site or personal blog, there are plenty of other services out there with generous free tiers. These are expectations that Microsoft and Github have created, and we need to unlearn some of that.
Mirroring
One thing I wanted to do is keep a presence on Github. This can aid in discoverability and for any of my existing projects it wouldn’t break anyone whose automation relies on pulling from that repo.
Thankfully, this is super easy. You can set up a push mirror in your repository settings in Forgejo. This generates an SSH key for you, which you add as a Deploy Key on the target Github repository. Jobs done.
Additionally, there’s a few nice tricks you can pull:
- Github will render
.github/README.mdinstead ofREADME.mdif it’s found. - You can use Github Actions to autoclose any issue or PR raised on the Github repository.
For an example of these, see on of my own repositories: https://github.com/daenney/longdistance/tree/main/.github. Feel free to steal the Actions workflows.
Once you’ve migrated you can disable issues in the repository settings. But you can’t disable PRs, so the autoclose workflow comes in handy.
Go module import paths
For anyone using Go, I would highly suggest using a “vanity” import path for your projects. This lets you move where the code is hosted without requiring people to change their imports.
This is extremely simple to do with something like Github Pages or Codeberg Pages. Or any static site host. Take a look at this repository for an example of how I manage that: https://github.com/daenney/go-modules.
There are fancier solutions too, but a single HTML file that you can copy-paste find-replace is all it takes. The Go proxy will cache your modules anyway, so the amount of traffic a site like this receives is very small.
Conclusion
It’s time to move. I’ll be slowly moving all my projects over in the next few weeks. All that will remain on Github is an empty shell of mirrors, with as many features of the platform disabled as possible (issues, projects, wiki, archival etc.) Eventually I might remove my Github repositories entirely.
For the time being I’ll maintain my account in order to be able to collaborate on any projects that are still canonically hosted on Github. Codeberg isn’t a suitable home for every project, and we’re going to need a few alternatives to show up that have the resources to support larger projects. I’m hoping the Linux Foundation might spin something up so the Cloud Native ecosystem can move.
Codeberg and Forgejo are also working on ForgeFed support, which would allow us to federate and decentralise code collaboration using forges. Yes yes I’m aware of patch-based workflows using e-mail and e-mail is decentralised. No I don’t like it, nor do I find it usable.