3 ms·
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
by Eikon 10mo ago
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 https://github.com/Barre/ZeroFS/tree/main/.github/workflows
- featherless 10mo agoI 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 10mo agoWhat do you use for the local cache?
- featherless 10mo agoJust wrote about my approach yesterday: https://jeffverkoeyen.com/blog/2025/12/15/SlotWarmedCaching/ 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.
- theLiminator 10mo agoWow, that's a very cool project.
- Eikon 10mo agoThank you!
- hedgehog 10mo agoZeroFS 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 10mo agoThis 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.