Hacker News Reader

Comment by gateauxd | Hacker News Reader

Curious what even is the alternative. The stickiness is quite high and risk is scary to swap providers.

Claude/codex has made the stickiness much less of a problem. We just say "no new repos in GitHub" and then put agents on refactoring the existing repos for GitLab compatibility.

This exactly. Moving from GitHub to Forgejo was much less of a problem than we thought when we just told Claude to figure everything out. Kinda crazy, but it worked.

Self-hosted $whatever, managed your way. CI/CD doesn't have to be dog-slow or ever go down when you need it, only when you do your upgrades yourself, as god intended it.

I personally use Forgejo + their built-in Actions stuff (mostly GitHub compatible), have one old Linux desktop as a server which runs Linux + Windows runners, one Mac Mini for macOS/iOS builds, using NixOS so I don't have to remember how things work, and it just keeps running 24/7, always there when I need it.

There's something to be said for the social availability that github brings. I'm far more likely to submit a pr for a bugfix to a project on gh than a random self-host site.

You can do your own ci/cd runner system, but you still rely on webhooks or triggers, when you aren't hosting the code.

> There's something to be said for the social availability that github brings. I'm far more likely to submit a pr for a bugfix to a project on gh than a random self-host site.

Yeah, that used to be the single favorable argument for GitHub, nowadays I think it might be the opposite, at least personally. If the contributor can't be arsed to join the community proper (and maybe get a sign-in code to their email, or whatever login you use), I think I prefer life without their drive-by PRs.

Here is the thing, we have self-hosted runners running behind our firewall and even those go down for these kinds of outages. All the jobs just sit in the queue and are never sent to our self-hosted setup at all.

> we have self-hosted runners running behind our firewall and even those go down for these kinds of outages

Sounds like it's not as self-hosted as you think, or you have some other unnecessary dependency on something here? As long as GitHub isn't the sole place for your SCM, why would your self-hosted CI runners go down just because GitHub goes down?

because github stops passing out the jobs in general. The self hosted runners are behind the actions runner controller: https://github.com/actions/actions-runner-controller

I see, you're still using GitHub for SCM? Then I understand why it stops working :P When I said "Forgejo + their built-in Actions stuff" I meant you use Forgejo for git too, not just self-hosting runners but then connecting them to someone else's infrastructure.

If you're already hosting the runners, why not host git too? It's even simpler than running your own workers/runners.

1. Why isn't observability setup to monitor the queue depth and alert?

2. Why aren't the CI runners self-healing?

1. we absolutely have these alerts and i get alerted, often before github updates their status page updated telling me about the actions failure.

2. because when github's actions api is down in certain, seemingly very common, ways even self hosted runners can't pick up the jobs

Forgejo, and Gitea are decent alternatives if you want to fully move off Github! If you are hoping to move away from only Github Actions, I've been working on a ~drop-in replacement for their control-plane + runner for the past few months. Each each job runs in a cross-platform vm so you can run your ci locally and update your checks. It's still beta, so I certainly wouldnt use it in prod just yet, but it's great if you want to run some of your CI locally. it allows me to extend it where possible to introduce some new features like JIT pipelines, improve performance or security. https://github.com/preloopdev/preloop if anyone's curious!

The alternative is, I’m guessing, probably any other hosted git + CI/CD service that doesn’t offer a free tier to zillions of users (human and LLM alike) so that their computing capacity isn’t in a constant arms race with growth.

What makes it sticky? I just don't see it. The declarative Github Actions manifests?

I imagine very few people use the wiki, because it's so subpar.

The issues are a problem, but this is why I always thought issues should be a core part of the Git repo, checked into it, sort of how Fossil does it. And so should the wiki, for that matter.

Built an issue tracker like that, that persists state as an event graph in your repo in a dedicated branch. It is vendor agnostic and works offline:

https://ljtn.github.io/epiq

Absolutely anything? GitHub slowly became a standard through market share. Concourse CI is much better, in fact nearly anything is better than GitHub as it doesn't have first class container support.

See, my main issue is with Actions. If that breaks, there's little alternative for the more complex flows. Minor infrastructure changes could be done manually through AWS, but complex deployments would have to be replaced. That's a big task even with AI.

The pull request system and related machinery is useful, but Gitlab and the ilk can do the same. Even self-hosted solutions like Gitea. But I don't particularly have a problem with that living in Github. If there's an outage, break glass, force push to main.

The actual Git repository hosting part is trivial. If that breaks, Git is distributed anyways, push and pull to any random remote storage. All you need is SSH. The main headache is that automations would break as they are usually hard-coded to a given origin. That is solvable in a pinch, and we have setup mirrors in the past.

It really depends on your use-case and how much you are tied to them (Github authentication?)

swarmfile was built to deal with this type of problem

Reply on news.ycombinator.com