š„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!
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