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

featherless 6 days ago | parent | next [-]

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.

	▲	hedgehog 6 days ago \| parent [-]
		Cool, that looks a lot nicer than the OBD scanner app I've been using.

▲

Eikon 6 days ago | parent | prev | next [-]

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

▲

featherless 6 days ago | parent | next [-]

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.

▲

esafak 6 days ago | parent [-]

What do you use for the local cache?

	▲	featherless 6 days ago \| parent [-]
		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.

▲

hedgehog 6 days ago | parent | prev | next [-]

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)?

	▲	Eikon 6 days ago \| parent [-]
		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.

▲

theLiminator 6 days ago | parent | prev [-]

Wow, that's a very cool project.

	▲	Eikon 6 days ago \| parent [-]
		Thank you!

▲

duped 6 days ago | parent | prev [-]

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

▲

gheltllck 6 days ago | parent [-]

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.

	▲	sunnyday_002 5 days ago \| parent [-]
		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.