Am I right in assuming it’s not the amount of payment but the transition from $0 to paying a bill at all?

I’m definitely sure it’s saving me more than $140 a month to have CI/CD running and I’m also sure I’d never break even on the opportunity cost of having someone write or set one up internally if someone else’s works - and this is the key - just as well.

But investment in CI/CD is investing in future velocity. The hours invested are paid for by hours saved. So if the outcome is brittle and requires oversight that savings drops or disappears.

Have you ever set up GitHub Actions? The outcome is brittle because of their platform, not because of my inability to do CI.

I use them minimally and haven't stared at enough failures yet to see the patterns. Generally speaking my MO is to remove at least half of the moving parts of any CI/CD system I encounter and I've gone a multiple of that several times.

When CI and CD stop being flat and straightforward, they lose their power to make devs clean up their own messes. And that's one of the most important qualities of CI.

Most of your build should be under version control and I don't mean checked in yaml files to drive a CI tool.

Exactly this. I've used Jenkins, Travis, CircleCI and all of them were so easy in comparison to the github actions runner mess.

This is not investment in CI/CD. I already did that, by buying and investing in my own hardware, my own workflows, my own caching solution.

This is like if Dropbox started charging you money for the files you have stored on your backup hard drives.

You're sounding a lot like a Microsoft damage control artist.

Keep this kind of comment on reddit, not here.

I'll keep it where I like actually, thanks.

The only company I’ve held a grudge against longer than MS is McDonalds and they are sort of cut from the same cloth.

I’m also someone who paid for JetBrains when everyone still thought it wasn’t worth money to pay for a code editor. Though I guess that’s again now. And everyone is using an MS product instead.

I'm curious, what are you doing that has over 1000 hours a month of action runtime?

I run a local Valhalla build cluster to power the https://sidecar.clutch.engineering routing engine. The cluster runs daily and takes a significant amount of wall-clock time to build the entire planet. That's about 50% of my CI time; the other 50% is presubmits + App Store builds for Sidecar + CANStudio / ELMCheck.

Using GitHub actions to coordinate the Valhalla builds was a nice-to-have, but this is a deal-breaker for my pull request workflows.

Cool, that looks a lot nicer than the OBD scanner app I've been using.

On ZeroFS [0] I am doing around 80 000 minutes a month.

A lot of it is wasted in build time though, due to a lack of appropriate caching facilities with GitHub actions.

[0] https://github.com/Barre/ZeroFS/tree/main/.github/workflows

I found that implementing a local cache on the runners has been helpful. Ingress/egress on local network is hella slow, especially when each build has ~10-20GB of artifacts to manage.

What do you use for the local cache?

Just wrote about my approach yesterday: https://jeffverkoeyen.com/blog/2025/12/15/SlotWarmedCaching/

tl;dr uses a local slot-based cache that is pre-warmed after every merge to main, taking Sidecar builds from ~10-15 minutes to <60 seconds.

ZeroFS looks really good. I know a bit about this design space but hadn't run across ZeroFS yet. Do you do testing of the error recovery behavior (connectivity etc)?

This has been mostly manual testing for now. ZeroFS currently lacks automatic fault injection and proper crash tests, and it’s an area I plan to focus on.

SlateDB, the lower layer, already does DST as well as fault injection though.

Wow, that's a very cool project.

Thank you!

1 hour build/test time, 20 devs, that's 50 runs a month. Totally possible.

GH actions templates don’t build all branches by default. I guess it’s due to them not wanting the free tier to use to much resources. But I consider it an anti-pattern to not build everything at each push.

That is because GH Actions is event based, that is more powerful and flexible than just triggering on every push and not letting it be configured.

``` on: push ```

is the event trigger to act on every push.

You'll waste a lot of CI on building everything in my opinion, I only really care about the pull request.