aayushshah15
Joined 7 years ago
Karma
35
Submissions
29
Member since
Oct 11
Recent submissions
Comment · 1 year ago
Yes! This is documented in our docs: https://docs.blacksmith.sh/blacksmith-caching/docker-builds#..., the TLDR is that you can use the `build-push-action` with `setup-only: true`.
Comment · 1 year ago
[cofounder of blacksmith here]
This is on our radar! The primitives mentioned in this blog post are fairly general and allow us to support various types of artifact storage and caching protocols.
Comment · 1 year ago
> one downside I've observed with some serverless in the past is that it can introduce up-front latency delays as the system spins up support to handle your spike
[cofounder of blacksmith here]
This is exactly one of the symptoms of running CI on traditional hyperscalers we're setting out to solve. The fundamental requirement for CI is that each job requires its own fresh VM (which is unlike traditional serverless workloads like lambdas). To provision an EC2 instance for a CI job:
- you're contending against general on-demand production workloads (which have a particular demand curve based on, say, the time of day). This can typically imply high variance in instance provisioning times.
- since AWS/GCP/Azure deploy capacity out as spot instances with a guaranteed pre-emption warning, you're also waiting for the pre-emption windows to expire before a VM can be handed to you!
Comment · 1 year ago
Some backstory on this: we've been working on a storage primitive to power incremental docker builds for Blacksmith's GitHub Actions runners. We realized early on that this was going to be a useful capability on its own since we notice a ton of our users with massive cache restore/save times in their workflows.
Fun fact, we decided to call it "sticky disks" as a result of this old HN comment thread: https://news.ycombinator.com/item?id=39957753
Comment · 1 year ago
> I'm unwilling to use graphite if I can't convince the rest of my team
OOC, what are the main objections against?
Comment · 2 years ago
That issue is from 2020 and has already been addressed. The fact that io_uring support is not "GA" is mostly a semantic aspect that doesn't affect most use-cases.
Comment · 2 years ago
> Firecracker didn't have a very compelling I/O story
Can you provide any sources for this claim? We're running Firecracker in production over at blacksmith dot sh and haven't been able to reproduce any perf regressions in Firecracker over CH in our internal benchmarking.
Comment · 2 years ago
We're noticing our development instances (which run on Fly.io) have been down for over an hour.
Comment · 2 years ago
I'm obviously biased here but this is what we do at blacksmith dot sh. We run you GitHub Actions on consumer grade desktop CPUs with high single core performance, all inside ephemeral Firecracker VMs. Give us a shot!