Putting the obvious facetiousness of this whole endeavor aside, doing something like this would mean that your reliability record is exactly as good as GHA
You misunderstand, (continued) runtime is dependent on the ability to deploy. For instance: a vulnerability is realized or a customer needs something (availability, feature, who knows), you'll appreciate handles under your control. Service can easily degrade, without.
I've done this same thing, GHA as a control plane. It was for people who could wait; the actual operators regularly skipped the middleman. Preference or necessity, take your pick.
Runtime is separate from deployment. An incident in your deployment infra doesn't affect production. The fact that you may have to deploy to change what's live is what defines it as an incident, but it's still a different thing from a production incident.
From "nothing to do with" to "separate", I'd say we're making progress.
Deployment is how you fix problems with the runtime. Not just availability, shortcomings. I'm not going back and forth about this, there is a relationship here. Man architects, God laughs.
Here's a fun phrase to latch onto: 'escape', production is the test environment we all share.
GitHub goes down, yes, your service remains. For now. We chose to not wait, suggest others don't either. I agree in spirit with the GP. Misfortune is the fortune that never misses.
This doesn't seem particularly interesting. Spinning up environments via PRs is nothing new. This just has a fresh coat of paint. Is it neat to pack everything up into a single unit like this? I don't know, maybe.
The most concerning thing here is that you absolutely should not use GitHub fucking Actions as your control plane. Have you ever debugged actions? It's terrible. Old runs magically disappear. The queue sometimes decides to go for a lunch break. Not to mention GitHub's uptime is atrocious.
I'm sorry (not sorry) but I can't take this seriously at all.
I dig the core concept, because it's what I'm replicating in my own homelab at present sans GHA and with a brief flirtation with Podman over Docker.
Thing is, like others have pointed out, relying solely on GHA is just not a great idea. If you're doing your own self-hosted runners you can effectively debug, then sure, that's not a bad idea necessarily, but using the GitHub runners?
Nope. Sorry, just not something I can trust on the free tier.
That being said, I do like the core concept (deploying the essentials to a plain-jane Debian instance - bare metal or virtual - and just bootstrapping via compose files and some form of push), and I'd like to see it refined more for homelab users, especially if you can guarantee some degree of security best practices with it (e.g., SELinux compatibility and/or auto-deploy tools like Wazuh).
I'll poke at it since I gotta blow away my Debian install anyway (went down a rabbit hole on GPU acceleration and Podman that has left it butchered far more than I would've liked to support), just give folks more options than GHA and focus more on essential services.
Except for when GHA is down, which is (from my own experience) waaaaay more often than our self-hosted GitLab, with it's much better CI system, ever was :)
Putting the obvious facetiousness of this whole endeavor aside, doing something like this would mean that your reliability record is exactly as good as GHA
It's ok, I hear they recently hit 5 9s of reliablility again! (89.9999%)
You misunderstand, this only deploys, has nothing to do with runtime.
You misunderstand, (continued) runtime is dependent on the ability to deploy. For instance: a vulnerability is realized or a customer needs something (availability, feature, who knows), you'll appreciate handles under your control. Service can easily degrade, without.
I've done this same thing, GHA as a control plane. It was for people who could wait; the actual operators regularly skipped the middleman. Preference or necessity, take your pick.
Runtime is separate from deployment. An incident in your deployment infra doesn't affect production. The fact that you may have to deploy to change what's live is what defines it as an incident, but it's still a different thing from a production incident.
From "nothing to do with" to "separate", I'd say we're making progress.
Deployment is how you fix problems with the runtime. Not just availability, shortcomings. I'm not going back and forth about this, there is a relationship here. Man architects, God laughs.
Here's a fun phrase to latch onto: 'escape', production is the test environment we all share.
GitHub goes down, yes, your service remains. For now. We chose to not wait, suggest others don't either. I agree in spirit with the GP. Misfortune is the fortune that never misses.
Their nines aren't yours, you bet.
Minor feedback: struggled to read this with the too-clever but distracting horizontal line scrolling down the page. Also the headers look squashed.
This doesn't seem particularly interesting. Spinning up environments via PRs is nothing new. This just has a fresh coat of paint. Is it neat to pack everything up into a single unit like this? I don't know, maybe.
The most concerning thing here is that you absolutely should not use GitHub fucking Actions as your control plane. Have you ever debugged actions? It's terrible. Old runs magically disappear. The queue sometimes decides to go for a lunch break. Not to mention GitHub's uptime is atrocious.
I'm sorry (not sorry) but I can't take this seriously at all.
Based on the feedback, I have created a page: https://towlion.github.io/platform/scope/
Hmm interesting, I wonder how much fiddling to make this work on an actual machine at home running fedora server
I dig the core concept, because it's what I'm replicating in my own homelab at present sans GHA and with a brief flirtation with Podman over Docker.
Thing is, like others have pointed out, relying solely on GHA is just not a great idea. If you're doing your own self-hosted runners you can effectively debug, then sure, that's not a bad idea necessarily, but using the GitHub runners?
Nope. Sorry, just not something I can trust on the free tier.
That being said, I do like the core concept (deploying the essentials to a plain-jane Debian instance - bare metal or virtual - and just bootstrapping via compose files and some form of push), and I'd like to see it refined more for homelab users, especially if you can guarantee some degree of security best practices with it (e.g., SELinux compatibility and/or auto-deploy tools like Wazuh).
I'll poke at it since I gotta blow away my Debian install anyway (went down a rabbit hole on GPU acceleration and Podman that has left it butchered far more than I would've liked to support), just give folks more options than GHA and focus more on essential services.
I'm not sure what this is for, most people already use GHA without any control plane and deploy just fine.
Except for when GHA is down, which is (from my own experience) waaaaay more often than our self-hosted GitLab, with it's much better CI system, ever was :)