SOC2 ?
Show HN: Open-source x64 and Arm GitHub runners
31–40 of 128 posts
Re: Show HN: Open-source x64 and Arm GitHub runners
#32Earlier quoted context omitted.
If the data is also encrypted at rest (as they claim it is), then even if the raw data is recovered it shouldn't be useable without a combination of key leak.
I work at Ubicloud. Although we have a KEK and DEK code for regular VMs, they are not operative on GHA...yet. The reason has to do with a technical conflict with copy-on-write we aim to close, not least of which because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. I expect within a few months, all expired GHA vms will be cryptoshredded upon their deletion. Th…
> because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today.
Just, why? CoW (or your own CoA) are ripe with performance problems. How exactly do you benefit from their use?
Re: Show HN: Open-source x64 and Arm GitHub runners
#33Our biggest GHA fees come from running on MacOS. Do you offer MacOS as a managed service (or plan to?) and how much cheaper is that than GitHub?
We support GitHub MacOS 13 runners on M2 Pros at WarpBuild [1]. They're about 25% faster and 50% cheaper per minute compared to the equivalent GitHub hosted runners. [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
Nice, I don't think you supported them last I looked. I'll be glad to get off GH's mac runners which are straight garbage, like it's embarrassing or it should be for them. The sheer audacity to charge 10x the linux runners and still be so slow... At 10x price they are 2x+ slower than the linux runners for doing the same thing (checking out repo, installing dependencies, running webpack).
Re: Show HN: Open-source x64 and Arm GitHub runners
#34We've been using Ubicloud builders for our Rust project [0] for several months, and it's worked very well. We've seen CI times go from 10-15 minutes to 6-7, and our bill has gone from $300/month to $30. One counter-intuitive thing we found is that it's slow to save and restore caches, but the machines have good CPU, so for us it's been faster to disable cache entirely and just redo everything on each build. [0] https…
> One counter-intuitive thing we found is that it's slow to save and restore caches, but the machines have good CPU, so for us it's been faster to disable cache entirely and just redo everything on each build. The link to SPDK was very interesting: https://www.ubicloud.com/blog/building-block-storage-for-clo... . I use filesystems for very high performance applications, and I've found ZFS to often be the limiting fac…
In this case, I don't think the issue is due to filesystem performance. Someone from Ubicloud can correct me, but my understanding is that for custom runners Github still stores the cache on their side. So Ubicloud (in Europe) needs to transfer the cache from Github (in the US) on every run.
Re: Show HN: Open-source x64 and Arm GitHub runners
#35We've been running Ubicloud for a while at Resmo. It is indeed 10x cheaper. We upped our instance sizes by 2x for a slightly more performance but it's still 5x cheaper.
The main reason is their platform is hosted on Hetzner dedicated instances.
Re: Show HN: Open-source x64 and Arm GitHub runners
#36[deleted]
Re: Show HN: Open-source x64 and Arm GitHub runners
#37We've been using Ubicloud builders for our Rust project [0] for several months, and it's worked very well. We've seen CI times go from 10-15 minutes to 6-7, and our bill has gone from $300/month to $30. One counter-intuitive thing we found is that it's slow to save and restore caches, but the machines have good CPU, so for us it's been faster to disable cache entirely and just redo everything on each build. [0] https…
Thanks for sharing! I've been looking at the repository and noticed that some jobs are still running on Github hosted runners. What is the point of using them and not running everything on Ubicloud?
Re: Show HN: Open-source x64 and Arm GitHub runners
#38Earlier quoted context omitted.
We support GitHub MacOS 13 runners on M2 Pros at WarpBuild [1]. They're about 25% faster and 50% cheaper per minute compared to the equivalent GitHub hosted runners. [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
Nice, I don't think you supported them last I looked. I'll be glad to get off GH's mac runners which are straight garbage, like it's embarrassing or it should be for them. The sheer audacity to charge 10x the linux runners and still be so slow... At 10x price they are 2x+ slower than the linux runners for doing the same thing (checking out repo, installing dependencies, running webpack).
That is correct. We went live with them about a week ago. Will likely introduce it to the HN friends in the next couple of days.
I agree with the stuff you've mentioned, obviously, but also empathize a bit with the GitHub folks because of all the licences and limitations Mac runners come with.
The perf for comparable operations is squarely on them though.
Re: Show HN: Open-source x64 and Arm GitHub runners
#39Earlier quoted context omitted.
I work at Ubicloud. Although we have a KEK and DEK code for regular VMs, they are not operative on GHA...yet. The reason has to do with a technical conflict with copy-on-write we aim to close, not least of which because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. I expect within a few months, all expired GHA vms will be cryptoshredded upon their deletion. Th…
> because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. Just, why? CoW (or your own CoA) are ripe with performance problems. How exactly do you benefit from their use?
The GitHub image is 86GB and people want an action VM to start reasonably quickly, so a full copy for every run isn’t going to work so well.
As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work.
Re: Show HN: Open-source x64 and Arm GitHub runners
#40Earlier quoted context omitted.
> One counter-intuitive thing we found is that it's slow to save and restore caches, but the machines have good CPU, so for us it's been faster to disable cache entirely and just redo everything on each build. The link to SPDK was very interesting: https://www.ubicloud.com/blog/building-block-storage-for-clo... . I use filesystems for very high performance applications, and I've found ZFS to often be the limiting fac…
In this case, I don't think the issue is due to filesystem performance. Someone from Ubicloud can correct me, but my understanding is that for custom runners Github still stores the cache on their side. So Ubicloud (in Europe) needs to transfer the cache from Github (in the US) on every run.
Hi, I work for Ubicloud.
Yes, that is correct. We are also working on implementing our own caching, which should speed up cache downloads/uploads significantly.