Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
crohr
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
28 ms
·
61.
▲
Show HN: I've compiled single-CPU speeds across GitHub Action runner providers
(runs-on.com)
2 points
by
crohr
3y ago
|
0 comments
62.
▲
Show HN: S3 Cache for GitHub Actions
(runs-on.com)
1 points
by
crohr
3y ago
|
0 comments
63.
▲
by
crohr
3y ago
I don't understand what makes the pricing a non starter. You mean the license pricing? If so, 300€/year for something that will save you thousands doesn't seem too expensive to me. If you're talking about the instances,
64.
▲
Show HN: GitHub Action Runner Images (AMI) for AWS EC2
(runs-on.com)
2 points
by
crohr
3y ago
|
0 comments
65.
▲
by
crohr
3y ago
I love to see examples in the wild of repos having switched to a non-official GitHub Action runner. I'm slowly preparing a collection of repo timings comparing GitHub vs Buildjet/Warpbuild/Ubicloud vs my own solution RunsOn.
66.
▲
by
crohr
3y ago
Just a catch with Hetzner vs AWS: pricing at AWS is per-second while Hetzner is per-hour, which is (very) inconvenient if you're launching ephemeral runners.
67.
▲
by
crohr
3y ago
One of the goal of my own hosted runner project [1] is to display the carbon cost and money cost after each run. Too many people are oblivious of the costs and I think as an industry it would be great to at least get the data points. [1]:
68.
▲
by
crohr
3y ago
You can reach 10x cheaper with just AWS, especially on the larger runner sizes. That is even including disk costs. I put a calculator for RunsOn at https://runs-on.com/calculator/
69.
▲
by
crohr
3y ago
Yes, I wonder when/if GitHub decides to drop prices at some point. But in the meantime I’ve recently released RunsOn [1] with the same promise (10x cheaper, faster) but the whole thing runs in your AWS account. [1] https://r
70.
▲
by
crohr
3y ago
I've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public. [1]: https://runs-on.com
71.
▲
Show HN: Runs-on: 10x cheaper GitHub Action runners
(github.com)
3 points
by
crohr
3y ago
|
0 comments
72.
▲
runs-on: [cheap,fast,self-hosted] runners for GitHub Action, in your AWS account
(github.com)
1 points
by
crohr
3y ago
|
1 comments
73.
▲
by
crohr
3y ago
Hello HN! I'm showing you RunsOn, a new service to launch self-hosted runners in your own AWS account, without the usual SaaS middleman. RunsOn is installed in one click with a CloudFormation template, which deploys a private GitHub Ap
74.
▲
by
crohr
3y ago
Exactly my experience as well: https://x.com/crohr/status/1732442731715113374 In the tests with my GitHub Action [1] that spawns ephemeral runners for any workflow, I found BuildJet bandwidth speed 10 to 20 times
75.
▲
by
crohr
3y ago
If you need machines with high number of CPUs, you can check https://github.com/runs-on/action which allows you to select any EC2 instance type as ephemeral runner. Plus it’s the cheapest on the market, open source, an
76.
▲
Show HN: Deployment previews for your pull requests, on servers you control
(pullpreview.com)
2 points
by
crohr
3y ago
|
0 comments
77.
▲
Ask HN: Things to consider (Security, SEO) when issuing subdomains to SaaS users
5 points
by
crohr
5y ago
|
2 comments
78.
▲
Legacy Without Nostalgia
(world.hey.com)
3 points
by
crohr
5y ago
|
0 comments
79.
▲
by
crohr
6y ago
Hi Alex, I think you’re confusing me with the original creators of PullReview. My other venture is packager.io, which you might remember as well. Congrats to you for the continued development of your on premise packaging solution!
80.
▲
by
crohr
6y ago
Hello! The first recommendation would be to find a docker image providing a mock for the service you want (e.g. [1]) and if not enough then you could provision those services on demand in an additional step executing before the pullpreview
81.
▲
by
crohr
6y ago
Hello, we thought about other providers as well, can you send me an email to discuss (should be in my profile)? Thanks!
82.
▲
by
crohr
6y ago
Hello, thanks for your comment and the great points you’ve made. Regarding security, we do believe that it is a selling point for many companies. You might be ok granting access to Circle CI or others, but for a new kid on the block that’s
83.
▲
by
crohr
6y ago
> The bulk of my spin up time is spent pulling the image. I never got around to figuring out how to do a good cache for it. With our approach you keep the same instance for the duration of a PR or branch, so you mostly incur the docker
84.
▲
by
crohr
6y ago
It may be simple for you to do, but you just described having to provision a server, manually checkout your code using SSH agent forwarding or HTTPS auth, setup your environment variables, and then launch the app. And manually repeat the la
85.
▲
by
crohr
6y ago
Hello, review apps are a hot topic it seems ;) Many companies have come with their own version of the concept, which in our experience doesn’t stand well the test of time (because the person that wrote the glue code left the company or docs
86.
▲
by
crohr
6y ago
Also, something we didn’t mention on the site but might be interesting for some people: we’re more than happy to provide guidance and consulting on how to migrate your app to Docker Compose if that could be a blocker. Think of it as a kind
87.
▲
by
crohr
6y ago
Yep, it’s also not limited to GitHub in any way and could be used straight from your dev machine or from other CI tools such as GitLab CI, Circle, Jenkins, etc.
88.
▲
by
crohr
6y ago
> Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. Actually the way it works now is that you keep the same server for the duration of a PR / branch. This means fa
89.
▲
by
crohr
6y ago
I didn’t know about FeaturePeek, thanks for mentioning. It looks very similar indeed. From a quick look I would say the main differences are that it doesn’t run on servers you control, and is limited to frontend code only? Also it’s pretty
90.
▲
by
crohr
6y ago
Hello, thanks for your comment! I had a look at the angular way of doing it: very nice to see other approaches! From a quick look it does seem to require quite a bit more steps and to be more limited in scope, but the documentation looks ve
More ›