aayushshah15 (u/aayushshah15)

aayushshah15 commented on Reverse engineering GitHub Actions cache to make it fast blacksmith.sh/blog/cache... · Posted by u/tsaifu

nodesocket · 5 months ago

I'm currently using blacksmith for my arm64 Docker builds. Unfortunately my workflow currently requires invoking a custom bash script which executes the Docker commands. Does this mean, I can now utilize Docker image caching without needing to migrate to useblacksmith/build-push-action?

aayushshah15 · 5 months 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`.

aayushshah15 commented on Reverse engineering GitHub Actions cache to make it fast blacksmith.sh/blog/cache... · Posted by u/tsaifu

movedx01 · 5 months ago

Anything for artifacts perhaps? ;) We use external runners(not blacksmith) and had to work around this manually. https://github.com/actions/download-artifact/issues/362#issu...

aayushshah15 · 5 months 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.

aayushshah15 commented on How the economics of multitenancy work blacksmith.sh/blog/the-ec... · Posted by u/tsaifu

shadowgovt · 7 months ago

Interesting writeup. I wonder somewhat what this looks like from the customer side; 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. I know the CI consensus seems to be that latency matters little in a process that's going to take a long time to run to completion anyway... But I'm also a developer of CI, and that latency is painful during a tight-loop development cycle.

(The good news is that if the spikes are regular, a sufficiently-advanced serverless can "prime the pump" and prep-and-launch instances into surplus compute before the spike since historical data suggests the spike is coming).

aayushshah15 · 7 months 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!

aayushshah15 commented on Show HN: Sticky Disks in GitHub Actions github.com/useblacksmith/... · Posted by u/aayushshah15

aayushshah15 · a 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

aayushshah15 commented on Stacked Diffs Can Be Expensive: Why You Should Do It More blacksmith.sh/blog/stacke... · Posted by u/mooreds

setheron · a year ago

Been using jujutsu which does stacked diffs. Just the use of GitHub UI still a shame for stacked diffs and I'm unwilling to use graphite if I can't convince the rest of my team.

aayushshah15 · a 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?

aayushshah15 commented on Prisma Postgres – Runs on bare metal and unikernels prisma.io/blog/announcing... · Posted by u/gniting

ahachete · a year ago

https://github.com/firecracker-microvm/firecracker/issues/16...

aayushshah15 · a year 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.

aayushshah15 commented on Prisma Postgres – Runs on bare metal and unikernels prisma.io/blog/announcing... · Posted by u/gniting

ahachete · a year ago

Last time I checked, Firecracker didn't have a very compelling I/O story, which made it in my opinion not completely adequate for running Postgres (or any other database).

In contrast, other similar VMM seem to have a better one, like Cloud Hypervisor [1]. Why then FC and not CH? (I've nothing against FC, actually love it and have been using it, but it appears not being the best I/O wise).

[1]: https://github.com/cloud-hypervisor/cloud-hypervisor

aayushshah15 · a year 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.