suryao

10 ms·

1. 91.▲
   by suryao 3y ago

   We maintain a little action called Action-Debugger that let's you ssh into a running GitHub action workflow to help debug pesky issues. It has a few additional features when you use it with our runners but works very well by itself. h
2. 92.▲
   by suryao 3y ago

   We already have a local container cache for speeding up dockerhub pulls. Automated container layer caching is coming in ~2 weeks. This will be present transparently so you'll be able to get the goodness with zero changes to your curren
3. 93.▲
   by suryao 3y ago

   That's true. We have a slightly different focus - CI workloads. However, the goodness of depot.dev comes from buildkit remote builders and remote cache. That'll be natively integrated into our runners in ~2 weeks. So you'll g
4. 94.▲
   by suryao 3y ago

   Yes. Graham is a great guy and I'm working with him to ensure it does.
5. 95.▲
   by suryao 3y ago

   You can continue to use actions/cache if using WarpBuild :)
6. 96.▲
   by suryao 3y ago

   Hey, thanks for the feedback. It's a decision I took to not support individual accounts since the github requirements usually suffice for those needs. The docs are wip - it'll be updated in the next couple of days.
7. 97.▲
   by suryao 3y ago

   I'll keep hn posted!
8. 98.▲
   by suryao 3y ago

   <3
9. 99.▲
   by suryao 3y ago

   You're right - I missed that VM OS in my illustration up there. Benchmarks are hard to come by but iirc, each VMM adds a 3-5% overhead. The gatekeeping for permissions and sandboxing that is done at each level involves active compute c
10. 100.▲
    by suryao 3y ago

    Check us out! We put some effort into the onboarding to make it super easy to use WarpBuild runners.
11. 101.▲
    by suryao 3y ago

    We do have high core options too (up to 16) but not crazy high like with GPUs. You'll probably still see good benefits. Could you elaborate on the pain points with using containers?
12. 102.▲
    by suryao 3y ago

    They are ephemeral VMs and are alive only for the duration of a single job. They are not reused.
13. 103.▲
    by suryao 3y ago

    Thanks for your trust! I'm here to ensure you have a good experience with WarpBuild and for feedback/requests.
14. 104.▲
    by suryao 3y ago

    Not yet, but coming soon (~2 weeks)
15. 105.▲
    by suryao 3y ago

    Yes. And to clarify to ensure no surprises, it's 2000 build minutes of the 2x runner. That's 1000min if on the 4x, and 25min on the 16x. It's twice more minutes if using the arm runners. May be easier to think of it as an $8
16. 106.▲
    by suryao 3y ago

    A very common use case for macos runners is iOS builds.
17. 107.▲
    by suryao 3y ago

    We don't enforce concurrency limits. It is not something that we want our users to think about. I'd hate to worry about it too. In general, we should be able to deal with spiky workloads of that scale without issue in a couple of
18. 108.▲
    by suryao 3y ago

    We do only 2x, 4x, 16x right now. We can add 32x but generally haven't seen much demand for it.
19. 109.▲
    by suryao 3y ago

    I don't have benchmarks but here's another comment from the thread. https://news.ycombinator.com/item?id=38571518
20. 110.▲
    by suryao 3y ago

    Right now, we are on a public cloud. We will be moving things onto our own infra with overflow on public clouds eventually. Try out the jobs once again - you should be okay (I think :) )
21. 111.▲
    by suryao 3y ago

    Thanks for the feedback! We are currently seeing fairly heavy load. The hn hug of death is real. Tweaked some settings and the startup delays should be back to the sub-10 second range in a few minutes.
22. 112.▲
    by suryao 3y ago

    There is a performance - cost envelope that we are pushing, which I believe github will be hard pressed to match. Also, this is the first step in our broader objective to: (a) support all CI providers (b) provide ecosystem support and tooli
23. 113.▲
    by suryao 3y ago

    Absolutely! We're working on it
24. 114.▲
    by suryao 3y ago

    VMs are a necessity if you are serious about security and isolation guarantees. I'd hope everyone else also uses it. I haven't run benchmarks but this comment provides a glimpse - https://news.ycombinator.com/item?
25. 115.▲
    by suryao 3y ago

    We have a few users who were using BuildJet try us out and they like it. It's an easy switch if you want to check it out.
26. 116.▲
    by suryao 3y ago

    That was oversight. Fixed it - thanks for pointing it out.
27. 117.▲
    by suryao 3y ago

    From a first-principles perspective, the stack is as follows: VMs on warpbuild: baremetal > hypervisor for VM > runner workload Container: baremetal > (cloud VM [1]) > k8s worker node OS > containerd > container OS > ru
28. 118.▲
    by suryao 3y ago

    There are 2 factors here: 1) I was being conservative on my promises. For instance, we have users who reported GHA runtimes going down from ~25m to ~9m [1] 2) Local builds have the amazing advantage of being able to cache subsequent runs. C
29. 119.▲
    by suryao 3y ago

    Thanks for taking the time to read my little launch and glad that it's clearer what we do. Try it out if you can, you will like the results :-)
30. 120.▲
    by suryao 3y ago

    We've had a few customers migrate over from BuildJet because WarpBuild is in active development. For instance, we are adding support for macos runners in Jan. Our mission is broader than just fast runners - it's about better CI de