18 comments

[ 0.19 ms ] story [ 7.8 ms ] thread
[flagged]
Does anyone write anything anymore themselves? This is insulting, even for an AI coding enthusiast like myself.
because you want to code and stand up ci runners yourself or because i just shared what i did for anyone to adopt including the code?

not sure what's insulting. I just shared why and how I did this, but hey.

I think it's about the comment you wrote, or rather that AI (appears to have) written entirely.
ah. it writes and i edit it. me and Stanley Duckenmiller. it's a way better writer than i am. so is my cousin who is a golf writer for 30 years. so you're correct. i am excellent at editing though :)
Your parent comment reads like AI slop, so you may not be as good at editing as you think. Worth thinking about the impression you’re conveying about yourself.
Yeah I completely gave up after a paragraph of overly wordy AI garbage.

There's no way just writing it out would have been worse

I’d suggest adding emdashes to your filter list.
I use this script for provisioning runners (with org-level single use access token).

https://github.com/vbem/multi-runners

The motivation is simply to have the runners share a local docker build cache rather than pushing and pulling cache from registry which is a ridiculous best practice.

This looks awesome and just what I need, with the difficulty of ARC in my corp environment
How is that not a native thing with Actions? GitLab had multi runners since early on.
I'm sure my scale is many magnitudes smaller but as a solo developer/founder I ran into this same issue recently as I've been creating more PRs than normal and also increasing my GH Actions usage for things like LLM review and just more unit/e2e/etc tests.

Last month I ran up $45 of overage spending (yes, I know, I know, this is tiny but for me it's not) and decided to make use of my homelab that was effectively twiddling it's thumbs most of time.

I settled on small VMs that I delete and restore from a snapshot after every run and it's worked out great so far. They only take up a tiny bit of ram when they are first started up and only take more from the system when they pick up a job. Even though each worker can use 6GB they rarely do and I can run 6-8 of these on my box safely (even if all use 6GB).

I used a custom image containing only what I needed and that's worked really well for me so far and it's easy to add more to it if needed in the future.

After this change I went from spending $2-4/day to <$0.25 (I left a few very small tasks on GH Actions).

It's not always the right call and for paid workers I'd reach for WarpBuild or similar most of the time (WarpBuild still runs my deploys/iOS builds) but for all the PR-check actions, those work just fine on my local server.

With Claude it was super easy to get set up. It's not a very complicated process at all but I was always unsure of the ROI for the time to set it up and tune it. After the overage bill I figured I'd try it out and it worked out even better than I had hoped for (including having a number of the jobs run faster since my workers were bigger/better/faster/stronger than the default GH worker, no surprise there). I even considered running 1-2 VMs on my MBP as well so it could pick up some of the load.

All that said, if your GH Actions bill is going up (which it probably is), I can highly recommend looking into running your own workers for at least part of the load.

thanks! mine hit $145. i'll have to check out your solution too.
We’ve been using runs on for maybe a year now. It’s a managed service for self hosted runners. Pretty great if you want to get off expensive GH actions boxes and do self hosting but don’t have the time to manage it yourself.

https://runs-on.com/

Shame this is AWS specific and not just a Docker image
I had a different plan in mind, keep everything in cheap s3, save a declarative script on a public repository that deploys forgejo and harbor containerized on the local ephemeral Origin/cache and pull heavy sources and code from s3.