šŸ”„Letā€™s Do DevOps: Supercharge your build speeds with Depot (Sponsored)šŸ”„

Join me this week as I see if we can speed up our docker builds using hosted images provided by Depot.dev!

Kyler Middleton
7 min readNov 5, 2024

This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can do it!

This article is sponsored by Depot.dev. My promise to you is to only promote products I believe in, and to always be transparent in which content is sponsored. More information is on this page.

Hey all!

This week Iā€™m investigating how to make hosted builds faster on GitHub. Or really any platform, but GitHub is where most of the code that I work with is stored at.

Depot reached out and offered me a chance to test out their new GitHub Actions Ultra Runners. Depotā€™s offering of hosted runners for your CI jobs has always been compelling ā€” they offer all sorts of runners, better caching, and better compute than GitHubā€™s own native hosted runners, and all at half the cost of what GitHub offering comes in at.

But Ultra Runners are a new improvement, which they claim make their runners 3x faster than GitHubā€™s native runners for some types of jobs. These runners use a RAM Disk, which uses up to 25% of memory for ultra-fast disk operations, which is great for file-intensive tasks.

The best news of all ā€” these Ultra Runners donā€™t cost anything extra, and anyone using Depot runners gets them immediately, for free, without any config changes. You can check if youā€™re using them at this link.

Iā€™m a huge fan of dropping build times as much as possible ā€” after all, if you arenā€™t testing your PR commits, are you really testing your code? And developers make a LOT of commits.

Depot runners didnā€™t win every contest I set for them, but they got to that green check mark a lot faster than GitHub Runners did almost every time!

Depot claims that these runners are significantly faster than the native GitHub runners, and in some cases are 3x faster. Lets test these claims with some Docker build tasks Iā€™ve built for my clients.

Letā€™s test them for real!

Setting Depot Runners Up

I want to register the Depot runners and run some jobs to compare how fast they are compared to GitHubā€™s native runners. First I checked to make sure there were no special runners in my Repo.

And then I clicked the big purple ā€œConnect to GitHubā€ button. I love when companies make their products easy to use.

I clicked my personal GitHub account, and I was immediately met with an error message ā€” I was attempting to register the runners in a personal GitHub account repo, which isnā€™t yet supported (I think because Depot uses a GitHub App, and GitHub individual accounts donā€™t support Apps). Whatā€™s great here is the detail of the error message ā€” itā€™s telling me exactly what I did wrong and how to fix it. Thatā€™s pretty cool.

Much better than the ā€œsomething went wrongā€ of other products Iā€™ve used.

They even sent me an email with the same info in case I missed it.

I quickly created a (free!) GitHub Org of my own, which if youā€™re in any type of Enterprise environment, youā€™re already using. I tried again, and this time selected my cool new GitHub Org instead.

Depot installs their runners as a GitHub Action, which means native GitHub Org security is in play ā€” this means you can either make the Runners available in any number of Repos, or across your entire Org.

I notably donā€™t see an analog for Enterprise Runners (those runners that would be available across the entire Enterprise), so if youā€™re interested in that you might need to contact Depot support or sales.

I give it access to a single Repo only just for fun.

And I get another error message. Iā€™m obviously doing great at this, but again, the error message is fantastically descriptive. I set this repo as a public one, with the intention that Iā€™d link yaā€™ll to it, but these runners donā€™t have access by default. I am provided a straight-forward method of fixing this, but also a warning on the GitHub page that doing so introduces ā€œsignificant security risks.ā€

Me being a chicken, I decided to make the Repo Iā€™m testing on a private one, and re-ran the job. Worked straight away.

And thereā€™s my runner in the repo, ready to go. Cool!

How To Test

I could write different Actions that call different runners, and build different images, but comparing them would mean stare and compare between different Actions, and having to manually verify that the code I was building was the same for apples to apples comparisons.

Much easier would be to tell Actions to build the same code with different runners, and even specify building all the same images together. This pattern is often used for terraform validations in my experience, and sometimes for testing applications on different platforms, and less so for building images like this.

However, itā€™s great for testing. Letā€™s walk through how I implemented it.

First, we create a name and set `on` triggers. The workflow_dispatch trigger means itā€™s kicked off by hand. I donā€™t need CI actions triggering the build (actually, a push to master/main would be pretty cool), so weā€™ll leave it simple.

Next we set up the job matrix. Letā€™s go line by line.

On line 3ā€“4 we set a strategy. The default strategy says if any of these jobs fail, to immediately cancel the other jobs. Partially completed runs are more trouble than they save in my opinion, so I disable this wherever I can.

On line 5 we setup a matrix using two different attributes ā€” ā€œrunnerā€ and ā€œimageā€. This says to spin off a job using every combination of these two attributes. You can find out the number of jobs with simple multiplication ā€” (number of runner attributes, being 2) times the (number of image attributes, being 2). Ergo, 2x2 = 4 jobs total will be run on each trigger.

On line 12 we start to consume the matrix attributes. We tell the runs-on attribute, which is a GitHub Actions key that specifies which runner label pool to use, to specify the same image as we see in the ā€œrunnerā€ matrix attribute. So half of the jobs will use the ubuntu-latest label, and half will use the depot-ubuntu-latest label.

That should give us some apples to apples comparisons! Nice.

But what is the job actually doing? Lets write the steps itā€™ll actually complete to build our image. Lets go line by line again.

On line 2ā€“3 we specify to download the code for our repo. Thatā€™s important so we can access the Dockerfile with our docker build command.

On line 5 we call the docker build command from the ā€œdockerā€ entity on GitHub, which is the Docker organization, and we call their build-push-action. We donā€™t need a real push to a container registry, but this task lets us just build the imagine only if we need to.

On line 8, we set a tag, which isnā€™t really used, but I was having fun with matrix attribute references, and on line 9 we set the poorly named ā€œcontextā€ of the task, which in reality means the directory where the commands are executed from. Since the code is actually in folders that are named after the matrix.image attribute, we tell it to look in that location for the files.

Results

Depot, you killed it! In both tests we came out ahead using the Depot runners. That surprised me, because I expected GitHub Runners are quite a lot ā€œcloserā€ network-wise to the code theyā€™re copying down, and any artifacts that code needs to run.

Test case 1: Ubuntu2004 image

  • GitHub Runner ā€” 2m39s
  • Depot Runner ā€” 2m7s
  • Winner ā€” Depot
  • Improvement ā€” 20% faster

Test case 2: Jekyll Builder image

  • GitHub Runner ā€” 15m49s
  • Depot Runner ā€” 12m8s
  • Winner ā€” Depot
  • Improvement ā€” 23.3% faster

Summary

During this article, we talked about the Runners that are available by default on GitHub Repos, and how to use them. We also logged into our fresh Depot.dev portal, and associated it to our GitHub Org.

We made the Depot GitHub Ultra Runners available on an individual Repo, and we confirmed they were there.

We wrote a GitHub Action using matrix pattern to tests in parallel the same code, so we can get an apples to apples comparison of the runner types.

We got it all working, then validated that the Depot runners are in fact faster than the GitHub hosted runners, by about 20ā€“25%! Thatā€™s pretty awesome.

More info on Depot GitHub Ultra Runners is here, and they offer a 7 day free trial (without a credit card, even!), so you can go validate these findings yourself, or test your own builds on these faster runners.

Thanks all! Good luck out there.
kyler

--

--

Kyler Middleton
Kyler Middleton

Written by Kyler Middleton

DevNetSecOps, DevRel, cloud security chick. I will teach you, itā€™s unavoidable. She/Her šŸ³ļøā€šŸŒˆšŸ³ļøā€šŸŒˆ, INFJ-A, support the EFF!

No responses yet