alt Hacker NewsOur deploys are tied to GitHub actions and it is becoming a liability at this point. What alternatives do people use? I mean for FOSS there are some decent stuff but we need a reliable provider for private repos.
Replies
Forgejo backed by Woodpecker CI running on Kubernetes (Talos) has been amazing! Ditch Github Actions syntax for the simplicity of Woodpecker and containers. You'll thank me later.
I self-host with GitSocial.
Git itself usually works, but we gave up on GHA and use https://www.rwx.com/ for tests, previews, and deployments. It’s 2x to 10x faster than GitHub Actions and testing uncommitted changes on real CI infrastructure is a total game changer.
Self-hosted Forgejo with a bunch of runners might also be interesting for you. The workflow syntax is _almost_ identical to the github one.
Some of our deploys use CircleCI instead, but they were still broken because they couldn't checkout from Github.
My deployments are tied to their container registry, so I'm equally screwed... Been thinking of going back to Dokku, I started working on a third wrapper around Dokku (yeah, I've literally done this twice already), and then self-host and self-provision... I honestly thinking seriously about this.
Genuine question: if you're hosting private repos, is self-hosting an option?
Gitea Enterprise would be worth looking at.
Post receive hook on a bare git repo with gitolite for access control.
self hosted forgejo has been my saviour. im thinking in acquiring a new NUC server to increase compute and storage to my homelab to add some new runners
You don't even have to migrate off GitHub if you don't want to.
Begin by refactoring the deployments so they're driven by checked in shellscripts, that accepts a git reference to deploy (prefer immutable commit SHAs over mutable branches/tags). Make it use the stuff it already has checked in, and make the actual GitHub Actions stuff as small and concise as possible, ideally each "run" should just call a shellscript with the git reference.
Then move so the deploys happen not on GitHub Actions itself, but on a "intermediate deploy host" that has the source code and access to the credentials you need, and make this host have one secure entrypoint, where someone (or something) can enter and run shellscripts, after pushing their code as a normal git push. Then switch so the deploys from GitHub Actions instead use this new host to do the deploys. Lock down this host hard.
When GitHub and/or GitHub Actions go down, the developer responsible for deploying stuff, should be able to get temporary git and ssh access to this host, can push any git data straight to the host, and their user on this host can run the deploy scripts. Keep in mind that nothing in your deployment process should depend on stuff that isn't also available on this "deploy host", if you have multiple synced repositories and so on.
Now things mostly work the same as people are used to, with the added benefit that when things go down again (like next week), you'll still be able to continue to deploy stuff.
I've done this refactor/migration for tens of companies in the last year, more or less following this exact template for all of them, with no issues reported from either of them, but lots of praise :)
[flagged]
We use GitLab where I work. The only problem is it calls pull requests "merge requests," and I don't think I'll ever get used to saying "MR" instead of "PR."