Hacker News Reader

Comment by woodruffw | Hacker News Reader

I think evaluating alternatives to GitHub is going to become increasingly important over the coming years. At the same time, I think these kinds of migrations discount how much GitHub has changed the table stakes/raised the bar for what makes a valuable source forge: it's simply no longer reasonable to BYO CI or accept one that can't natively build for a common set of end-user architectures.

This on its own makes me pretty bearish on community-driven attempts to oust GitHub, even if ideologically I'm aligned with them: the real cost (both financial and in terms of complexity) of user expectations around source forges in 2026 is immense.

View on HN

I don't understand the hype around CI and that it's supposedly impossible to run something like that without Git, let alone Github. Like sure, a nice interface is fine, but I can do with a simpler one. I don't need a million features, because what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here? It can probably be built internally if needed and it certainly doesn't need to depend on git so much - git can trigger it via hooks, but that's it?

I think the real problem is we were sold all these complex processes that supposedly deliver better results, while in reality for most people and orgs it's just cargo culting, like with Kubernetes, for example. We can get rid of 90% of them and be just fine. You easily get away without any kind of CI in teams of less than 5-7 people I would argue - just have some sane rules and make everyone follow them (like run unit tests before submitting a PR).

> just have some sane rules and make everyone follow them (like run unit tests before submitting a PR)

and thus you discover the value of CI

You could also just get managers that are not worthless.

I find CI very valuable even on my solo projects.

> what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here?

The key is hermetically/reproducibly - you don't want to run commands on some random machine, you want to run commands on a well-controlled/versioned machine that won't change under you, that you can recreate at will. Which sure you should be able to do with Nix or something, but the kind of person who doesn't want to use CI doesn't want to use Nix either.

And the other key is whose machine? Particularly when it comes to e.g. Macs, which are expensive. Maybe you have a spare server farm in your closet, but most people don't.

For a solo dev, what are the advantages of _not_ building on your own machine?

Is the compiling and test running too resource intensive?

Do you build every commit? If so, why?

I see the value in larger teams, but for solo stuff I just find it slow and annoying. I'm using go, and it compiles fast, so that could be a part of it.

> For a solo dev, what are the advantages of _not_ building on your own machine?

I end up with all kinds of random crap on my own machine. It's very easy to accidentally e.g. globally install a library that wasn't properly listed in my dependency management. So having a separate standardised/controlled build environment is a good way to catch those. It also helps with flaky tests or random "works on my machine" problems - this way my tests are at least getting run on two quite different machines (different OS/arch/etc.)

> The key is hermetically/reproducibly

Why not use VMs? Libvirt is scriptable enough for that. And LXC/Incus can be used if you want the shorter starting time.

Ok, that solves like 20% of the problem. How (and where) are you provisioning these VMs? How are you managing what versions of what are installed on them, and is that process reproducible?

None of this is hard, exactly, but you do have to put in the legwork of doing it, and it's mostly only the big players who've done so.

A lot of VM managers allows to clone from a disk. And some even allows for an overlay layer on top of a read-only disk.

Creating a build machine is not rocket science.

It's not rocket science. As I said, it's a case of doing the legwork. But you do have to actually do the work rather than just handwave it away. Ok, your VM manager allows you to clone from a disk and maybe allows you to have an overlay layer. Great. Now draw the rest of the owl.

These days the reproducibility part is trivial with a Docker container, as much as it's a mess of a technology.

Docker containers are great until you need to upgrade something. Then what do you do, rebuild the container and hope that none of the things that change break anything in a surprising way?

GitHub CI lets me test my package, for free, in all these: https://github.com/ncruces/go-sqlite3/wiki/Support-matrix

Which is actually useful.

The big deal is that GitHub provides it for free. Plus it integrated properly into the PR workflow.

Good luck implementing merge queues yourself. As far as I know there are no maintained open source implementations of merge queues. It's definitely not as trivial as you claim.

> it's simply no longer reasonable to BYO CI

Why? I know plenty of teams which are fine with repo and CI being separate tools as long as there is integration between the 2.

Actions are bad, but they're free (to start) and just good enough that they're useful to set up something quick and dirty, and tempt you to try and scale it for a little while.

Exactly. Any github alternative needs to consume same GithubActions syntax OOTB I'm afraid.

Which, as far as I found so far, means Forgejo. Haven't found any others. And even Forgejo Actions says that it's mostly the same as Github Actions syntax, meaning you still have to double-check that everything still works the same. It probably will, but if you don't know what the corner cases are then you have to double-check everything. Still, it's probably the best migration option if you rely on GHA.

Gitea also, I think.

Emphasis on teams; the median open source project has a fraction of a single person working on it.

CI needs good integration into the source forge. But I don't really perceive Github actions as a huge benefit over the times when everone just set up CircleCI or whatever. As long as it can turn PR checks red, yellow and green and has a link to the logs I'm happy

The whole PR and code review experience is much more important to me. Github is striving to set a high bar, but is also hilariously bad in some ways. Similarly the whole issue system is passable on Github, but doesn't really reach the state of the art of issue systems from 20 years ago

Working with all these modern layers, I don't see why people bother so much about it. This is all upper level decision to centralize so they feel they keep control. As a dev I'm 100% confident life would be as least as pleasant without all this abysmal layers of remote services that could all be replaced with distributed solutions that work 100% in local with thin sync step here and there.

> it's simply no longer reasonable to BYO CI or accept one that can't natively build for a common set of end-user architectures.

GitHub’s hosted runners support a grant total of two architectures.

The only forges which I’ve seen with more variety are distributios’ forges usually hosting their own runners.

I probably should have said platform tuples, I guess. I'm not aware of a free alternative to GitHub that gives me (AMD64, ARM64) x (macOS, Windows, Linux).

Reply on news.ycombinator.com