crohr

11 ms·

31.
Show HN: Magic Cache for GitHub Actions(runs-on.com)
2 points by crohr 2y ago|0 comments
32.
by crohr 2y ago
(it's now available: https://runs-on.com/runners/windows/ )
33.
by crohr 2y ago
Only r8g (large-memory instances) haver the latest CPU, hence the higher price, but this will make its way into c8g / m8g family types pretty soon I suppose. At this point they'll be same price (or probably cheaper) than c7g &#x2F
34.
by crohr 2y ago
AWS recently released their r8g instance family with their latest Graviton4 arm CPU. I took it for a spin and added it to the benchmark I maintain of the fastest EC2 instances. And it results in an impressive 25% faster CPU speed compared t
35.
New AWS Graviton4 arm instances are 25% faster than previous generation(runs-on.com)
1 points by crohr 2y ago|4 comments
36.
by crohr 2y ago
Thanks, I'll ping you when it's available!
37.
by crohr 2y ago
I'm working on https://runs-on.com , a self-hosted solution to get 10x cheaper GitHub Actions runners with support for Linux x64 and arm64. This month I've been refining Windows support and hopefully this gets fully shi
38.
by crohr 2y ago
> self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s) I’m the maintainer of RunsOn ( https://github.com/ru
39.
by crohr 2y ago
Another option is to simply cache layers in a fast cache close by (e.g. S3) ? Like https://runs-on.com/features/s3-cache-for-github-actions/#us... ?
40.
by crohr 2y ago
You could also be interested in https://runs-on.com . Must be installed in your AWS account (1-click cloudformation template), and then you can use any instance type offered by AWS.
41.
by crohr 2y ago
It’s going to be easier to maintain and cheaper. Plus you get compatible images included and more flexible runner assignment. But if you’re already happy with ARC then there is no real need to switch. RunsOn is really for people who want mo
42.
by crohr 2y ago
The software is on-premise, as in it runs on infrastructure you control, as opposed to a SaaS. Self-hosted might be the better term, but in the context of self-hosted GitHub runners, it’s a bit of a mouthful to say self-hosted solution for
43.
Show HN: GPU runners for GitHub Actions, 10x cheaper(runs-on.com)
7 points by crohr 2y ago|3 comments
44.
by crohr 2y ago
RunsOn is the only on-premise solution of the bunch, so it is single tenant, and as such it cannot easily have pools of 10s of machines on standby to start within 10s. So on queue time I’m comparing Ubicloud against the other SaaS provider
45.
by crohr 2y ago
> We were using self-hosted runners which were not as efficient as we thought so we spawned EC2 instances and connected them to the github network to be runners, but we had such an amount of issues that we wanted to go back to non-self h
46.
by crohr 2y ago
The queue time for x64 appears to vary quite a bit still. But you are correct that it is much better than what it was a few weeks back, when the analysis was written (it was not unusual to see 60s+ spikes). Also note that I specifically men
47.
by crohr 2y ago
Also a bit weird that they now seem to delegate the image building to third-party vendors (first GPU images, now ARM). Would be nice to know how they validate base images before distributing them to everyone.
48.
by crohr 2y ago
Much welcome addition, although not available (yet) on free plans. I benchmarked them and they are ~15-20% slower than AWS Graviton processors: https://runs-on.com/benchmarks/github-actions-runners/#arm64... But a
49.
by crohr 2y ago
m7i CPU is in the same ballpark figure than m7a ( https://runs-on.com/benchmarks/aws-ec2-instances/ ). When you look at the interruption percentage for m7a I think m7i (not m7i-flex if you don't want burstable
50.
by crohr 2y ago
> while we can boot the Actions runner within 5 seconds of a job starting, it can take GitHub 10+ seconds to actually deliver that job to the runner This. I went the same route with regards to boot time optimisations for [1] (cleaning u
51.
by crohr 2y ago
Any time I see engineering time spent on splitting/sharding test suites, I can't help but wonder if access to a single beefier runner (e.g. 64+ cpus) would have alleviated all that work. Also always find the duplicated setup time
52.
Show HN: Managed GitHub Action Providers Benchmark(runs-on.com)
2 points by crohr 2y ago|1 comments
53.
by crohr 3y ago
Oh yes, it can't work with GHA hosted runners otherwise you'll pay egress fees. From your first post I was assuming you were starting from the point of view that you would be running your own runners already. It does work as adver
54.
by crohr 3y ago
What you are looking for is a local S3 cache, which buildx supports as a backend. Just make sure you have an S3 gateway connected to your VPC (and that your S3 bucket is in the same region than your runners!) and enjoy free bandwidth, unlim
55.
by crohr 3y ago
I believe the solution is to decentralise, i.e. let the customer run the machines in their own AWS account (what I'm doing with RunsOn, link in bio if interested). It is very hard for a single player to get favourable treatment from Az
56.
by crohr 3y ago
Yes, BuildJet runs from Hetzner - https://runs-on.com/reference/benchmarks-gha-providers/
57.
by crohr 3y ago
If you’d like to try something else, RunsOn supports any type of account ( https://runs-on.com ). No MacOS though.
58.
by crohr 3y ago
Great to see some improvements on that front. CloudFormation is perfect for point-and-click install of third-party software (like mine [1]), but the slowness doesn't make for a great first impression when setting everything up. Really
59.
by crohr 3y ago
You're right, just added m5zn. Base frequency is 3.8Ghz and turbo boost 4.5Ghz, but since it is an outdated CPU, they are average at best. I'll also benchmark the z1d.
60.
What's the fastest EC2 instance CPU?(runs-on.com)
22 points by crohr 3y ago|8 comments

More ›