Last month we introduced managed GitHub runners. With a one-line change to the workflow definitions, your GitHub actions will run on Namespace infrastructure. And we will run them fast!
Surely I don’t need to sell you the benefits of fast CI. We all remember times we were impatiently watching the GitHub Actions page. Waiting to see if your pull request can finally be merged or if it needs one more cycle of fixing the tests and waiting for the CI again.
We noticed that our colleagues at Sentry feel the pain of slow CI too (great write-up, btw!). Our takeaway is that having access to parallelism in CI while keeping the costs manageable is the key. So we thought, can Namespace be of help?
Sentry Case Study
At Namespace, we are fans of Sentry. We use it for both our backend and frontend. And there were countless times it saved us when an unforeseen code path misbehaved in production.
Sentry tests turned out to be a perfect way to put our managed runners to the test (pun intended). It’s fairly representative of a typical project with a Python backend and a Node.js frontend. Its CI runs 14k backend tests and starts six backends in the ephemeral test environment. The frontend test suite includes 5.5k browser-based tests that run in parallel making full use of the RAM available on the runner.
So we did a trial run of Sentry CI on Namespace managed runners. We are not affiliated with Sentry, so we did this on our own based on the public source code available on GitHub. We set up a shadow clone of the sentry repo and modified the workflow files in our fork.
Results
I will let the numbers speak for themselves:
Frontend: 5m 31s vs 11m 27s.
Backend: 15m 3s vs 21m 30s.
Hence, for the Frontend workflow our Runners are 55% faster, while for the Backend workflow they are 28% faster.
What’s next?
Setting up our Managed Runners takes 10 minutes. Just get started.