Funny how Microsoft products tend to instill blindness over time; refocusing on git hooks (and not the UI) can offer some perspective.

At work we've started switching to codeberg (which uses forgejo) and honestly it's a breath of fresh air compared to GitHub. It's blazing fast compared to GitHub and has feature parity with our needs.

Not an option for the majority of companies as it only allows open source repositories as far as I'm aware.

Tangled.org

Selfhosting gitea is trivial, I'm saying this as someone who has been doing it at work for almost 6 years. Our experience has recently prompted another org (run by people we know) to move off GitHub, they also seem to be happy.

There are plenty of alternatives to Github, from Gitlab and Gittea to Forgejo, but Codeberg is not one of them, which is what I wanted to stress.

I have (almost completely) moved my business from GitHub to Forgejo as well. I’m deploying an instance at home as well.

It’s shocking how bloated and slow GitHub is even for basic actions when you compare it to Forgejo running just your own stuff.

Bonus: if you can manage to reliably backup a database and a filesystem, you can then backup your forge. Outside GH Enterprise there is still no restorable backup option inside GitHub.

This is great to hear! I’ll check it out.

How is it for usability (other than speed) compared to GH. Given that most/all devs are already comfortable in GH. What are the downsides in your experience?

A bit late on my reply here, sorry.

There are minor clumsy points here and there in the UI, but nothing major and nothing that’s a stumbling block.

It’s hard to paint a perfect comparison without using the same features but all the basics are there and working.

The version we have in use doesn’t support a gist functionality but the last I looked there was a PR for a similar feature with a less-GH—lawyer-baiting name. That was the biggest thing for me.

It has a GH Actions compatible rubber system too.

Forge, Gitea, and git itself contains a cgi script with quite a bit of functionality. And of course, the way it is supposed to work, git-over-ssh, as in give committers Linux shell accounts on a shared machine, with the CGI script running for pretty pictures (Remember CGI? You know, "cloud functions" before such a thing existed)

Huh, I should make an Apache plugin that launches docker exported containers uploaded into a directory.

Why a shared machine? Git was “supposed” to work with email. Do that.

That would be a huge downgrade for most users.

So is managing a shared Linux central repository…

I'm a contractor so have worked on a lot of different projects for different companies, big and small and also early startups.

This is far from truth imo. It is very possible to only use (F)OSS. Github, AWS, Azure, Vercel are not at all more pleasant or easier to work with than on-prem Gitlab/gitea/codeberg/jenkins/k8s/kibana/prometheus/grafana.

I could spend an hour and have a full setup done on physical or VPS to have 1) remote git hosting 2) pipelines running on changes 3) pipelines publishing images or some artifacts 4) automated deployment for these images/artifacts

I'm struggling to see what am I missing. What is worthwhile that Github offers? It is popular and easy to set up org+repos, but that seems it. A few years ago I was working on Azure Devops with the azure pipeline and that was the worst developer experience I've ever had. AFAIK Github actions uses the same syntax and works the same way, at least it was at that time.

What you're missing is maintenance, security, scaling, and protection from data loss.

Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.

Your CI has to be fully codified, stateless and possible to redeploy with a single command. That's the only way it can remain sustainable. No persistent hidden state, no manual configs (even as an option!) and automatically rebuilt on every release as the new version is deployed.

As a really big bonus, that also makes your CI testable.

In the previous job, we built such a thing: https://smarketshq.com/building-a-reproducible-ci-system-for...

Yes, totally agreed in theory, and it sounds like y'all built a great solution for your use case. But it takes substantial effort and discipline to do something like that at scale.

At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.

ah that point gha is not much of an help anyway

>I could spend an hour and have a full setup done on physical or VPS to have 1) remote git hosting 2) pipelines running on changes 3) pipelines publishing images or some artifacts 4) automated deployment for these images/artifacts

This sounds like a week or two of work to me (I'm a novice though). You should write a guide.

on the other hand, a better user experience is something open source projects can aspire towards as a pure goal, with no perverse incentives pulling them the other way. a lot of the recent github changes have degraded the user experience because that was overall more profitable for the company.