3 ms·

Hey, @jacobwg, this looks great. I couldn't find it anywhere on the page, but do you support Graviton3 (i.e. m7g instances) for GHA Runners? If the answer is n

Hey, @jacobwg, this looks great. I couldn't find it anywhere on the page, but do you support Graviton3 (i.e. m7g instances) for GHA Runners? If the answer is no, are there any plans to support it in the future? > start them when an actual job request arrives, to keep job queue times around 5 seconds Did you have to fine-tune Ubuntu kernel/systemd boot to reach such fast startup times?

playingalong 3y ago
Not affiliated, just guessing. This 5 seconds might be the warm start, not cold. I.e. they likely have a pool of autoscaled, multi tenant workers
- 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_ from preinstalled software!
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-supported-configurations https://depot.dev/docs/github-actions/overview#depot-support.... The challenge with Arm is actually just that GitHub doesn't have a runner image defined for Arm. For the Intel runners, we build our image directly from GitHub's source[0], and we're doing the same for the Arm runners by patching those same Packer scripts for arm64. It also looks like some popular actions, like `actions/setup-*`, don't always have arm support either. So the disclaimers for launching Depot `-arm` instances at the moment is basically just (1) we have no idea if our image is compatible with your workflows, and (2) those instances take a bit longer to start. On achieving fast startup times, it's a challenge. :) The main slowdown that prevents a <5s kernel boot is actually EBS lazy-loading the AMI from S3 on launch. To address that at the moment, we do keep a pool of instances that boot once, load their volume contents, then shutdown until they're needed for a job. That works, at the cost of extra complexity and extra money - we're experimenting some with more exotic solutions now though like netbooting the AMI. That'll be a nice blog post someday I think. [0] https://github.com/actions/runner-images/tree/main/images/ubuntu https://github.com/actions/runner-images/tree/main/images/ub...

playingalong 3y ago

Not affiliated, just guessing. This 5 seconds might be the warm start, not cold. I.e. they likely have a pool of autoscaled, multi tenant workers

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_ from preinstalled software!

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-supported-configurations https://depot.dev/docs/github-actions/overview#depot-support.... The challenge with Arm is actually just that GitHub doesn't have a runner image defined for Arm. For the Intel runners, we build our image directly from GitHub's source[0], and we're doing the same for the Arm runners by patching those same Packer scripts for arm64. It also looks like some popular actions, like `actions/setup-*`, don't always have arm support either. So the disclaimers for launching Depot `-arm` instances at the moment is basically just (1) we have no idea if our image is compatible with your workflows, and (2) those instances take a bit longer to start. On achieving fast startup times, it's a challenge. :) The main slowdown that prevents a <5s kernel boot is actually EBS lazy-loading the AMI from S3 on launch. To address that at the moment, we do keep a pool of instances that boot once, load their volume contents, then shutdown until they're needed for a job. That works, at the cost of extra complexity and extra money - we're experimenting some with more exotic solutions now though like netbooting the AMI. That'll be a nice blog post someday I think. [0] https://github.com/actions/runner-images/tree/main/images/ubuntu https://github.com/actions/runner-images/tree/main/images/ub...