jacobwg

6 ms·

31.
by jacobwg 2y ago
Depot | Founding Developer Marketer | Remote (US / EU) | Full-time Depot is a build acceleration platform that makes Docker builds and GitHub Actions faster. We've already helped companies like PostHog, Wistia, Semgrep, and Secoda
32.
by jacobwg 2y ago
https://youtu.be/E9yZ0JusME4 and the CEO on Twitter are the main sources for Arc being in maintenance mode as they work on their new product.
33.
by jacobwg 2y ago
The dates feel like intentional deception. The community question is "how long have you been discussing trademark usage?" and the answer is "I had lunch in February 2023!" Like somebody not trying to be deceptive would s
34.
Uncovering disk I/O bottlenecks in GitHub Actions(depot.dev)
2 points by jacobwg 2y ago|0 comments
35.
Possible security incident for Bitbucket and Docker Hub(dockerstatus.com)
3 points by jacobwg 2y ago|0 comments
36.
by jacobwg 2y ago
Yeah in our case we are operating a private registry on behalf of our customers, so slightly different use-case than running your own registry for your own internal use. If you do want to run your own registry, there's some great OSS p
37.
by jacobwg 2y ago
Data transfer costs. Our registry is for our customers, and they expect to pull their images from environments outside AWS, e.g. GitHub Actions. If that customer has a 2GB image, they want to build the image and then pull it into 10 separat
38.
by jacobwg 2y ago
Uploading in chunks could definitely solve the issue, and the OCI Distribution Specification does actually have some language about an optional chunked push API[0]. Unfortunately very few of the registry clients actually support this, criti
39.
by jacobwg 2y ago
The annoying thing about trying to implement a Docker registry on Workers and R2 is that it's so close to having everything you need, but the 500MB request body limit means Workers is unable to accept pushes of layers larger than 500
40.
by jacobwg 2y ago
Kinda - what we're seeing at Depot ( https://status.depot.dev/clyrvud6i57402igofm6jtb7id ) is that the APIs for managing Actions runners or retrieving work are receiving rate limit errors, interestingly missing the regul
41.
by jacobwg 2y ago
Not a coincidence, no. From the "self-hosted" perspectively, interestingly what we're seeing at Depot ( https://status.depot.dev/clyrvud6i57402igofm6jtb7id ) is API requests to provision new runners or receive
42.
GitHub Actions Outage(githubstatus.com)
48 points by jacobwg 2y ago|16 comments
43.
Multi-Version Schema Migrations(xata.io)
2 points by jacobwg 2y ago|0 comments
44.
Bufstream: Kafka at 10x Lower Cost(buf.build)
4 points by jacobwg 2y ago|0 comments
45.
Making EC2 boot time faster(depot.dev)
275 points by jacobwg 2y ago|140 comments
46.
We reverse-engineered the GitHub Actions cache(depot.dev)
1 points by jacobwg 2y ago|0 comments
47.
by jacobwg 2y ago
Not that I'm aware of, no, just the local state school. My impression of the YC application process was that it was way more holistic than just educational background.
48.
by jacobwg 2y ago
I mean, I didn't even graduate college :P > So we're just doing it on our own. IMO if you can become a $100M household name without VC, that's absolutely the way to do it. Even if you do take the VC path, YC for me was a m
49.
by jacobwg 3y ago
Correct yeah, each run starts on a brand new VM with a brand new disk - since these are EC2 instances with EBS volumes for their root disk, the whole instance and the EBS volume are deleted after the job finishes and are not reused.
50.
by jacobwg 3y ago
Yeah, I think our goal is to be the fastest at building software, not necessarily the cheapest. Part of that involves AWS, to have access to more powerful and elastic infrastructure, but that comes at a premium. But besides just compute, I
51.
by jacobwg 3y ago
Hey, we are building our base image from the runner-images repo! I'll send you an email!
52.
by jacobwg 3y ago
At the moment, I think you'd want to use both products together, i.e. using `depot build` in place of `docker build` to move the container build portion to a Depot container builder. I'd like to have a more automatic integration a
53.
by jacobwg 3y ago
Hey, yep we have this today! Depot's original product is a fully-managed container build service ( https://news.ycombinator.com/item?id=34898253 ) that caches all BuildKit layers to SSDs, so there's no cache-to&#x2F
54.
by jacobwg 3y ago
We do get the promised throughput, but it depends on the destination as you've discovered. AWS actually has some docs on this[0]: - For instances with >= 32 vCPUs, traffic to an internet gateway can use 50% of the throughput - For i
55.
by jacobwg 3y ago
Thank you!
56.
by jacobwg 3y ago
Yeah, GitHub's runners, especially the ones with >2 CPUs, have surprisingly long start times!
57.
by jacobwg 3y ago
Yeah this is a good option if you'd like something to deploy yourself! You can also build an AMI from GitHub's upstream image definition ( https://github.com/actions/runner-images/tree/main/image
58.
by jacobwg 3y ago
We don't re-use the VMs - a VM's lifecycle is basically: 1. Launch, prepare basic software, shut down 2. A GitHub job request arrives at Depot 3. The job is assigned to the stopped VM, which is then started 4. The job runs on the
59.
by jacobwg 3y ago
Yeah 5 seconds is from stopped to running, but to get that speed we need to pre-initialize the root EBS volumes so that they're not streaming their contents from S3 during boot. The GitHub Actions runner image is 50GB in size _just_ fr
60.
by jacobwg 3y ago
We do support Graviton! I actually _just_ enabled them today, which we're calling "beta" for the moment: https://depot.dev/docs/github-actions/overview#depot-support... . The challenge with Arm is ac

More ›