3 comments

  • SOLAR_FIELDS1 hour ago
    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
  • stego-tech52 minutes ago
    I dig the core concept, because it&#x27;s what I&#x27;m replicating in my own homelab at present sans GHA and with a brief flirtation with Podman over Docker.<p>Thing is, like others have pointed out, relying solely on GHA is just not a great idea. If you&#x27;re doing your own self-hosted runners you can effectively debug, then sure, that&#x27;s not a bad idea necessarily, but using the GitHub runners?<p>Nope. Sorry, just not something I can trust on the free tier.<p><i>That being said</i>, 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&#x27;d like to see it refined more for homelab users, <i>especially</i> if you can guarantee some degree of security best practices with it (e.g., SELinux compatibility and&#x2F;or auto-deploy tools like Wazuh).<p>I&#x27;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&#x27;ve liked to support), just give folks more options than GHA and focus more on essential services.
  • xyzzy_plugh1 hour ago
    This doesn&#x27;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&#x27;t know, maybe.<p>The most concerning thing here is that you absolutely should not use <i>GitHub fucking Actions</i> as your control plane. Have you ever debugged actions? It&#x27;s terrible. Old runs magically disappear. The queue sometimes decides to go for a lunch break. Not to mention GitHub&#x27;s uptime is <i>atrocious</i>.<p>I&#x27;m sorry (not sorry) but I can&#x27;t take this seriously at all.