I’ve been spending a lot of time helping companies to adopt GitHub ARC over the last few months. They are excited to be able to create self-hosted runners on-demand on Kubernetes. The biggest challenge many of them have is getting started, and the root of this problem often starts with realizing there are two different versions of ARC. In many cases, they started with the wrong one. This post will explain the difference.

GitHub’s Actions Runner Controller (ARC) offers a lot of great features, including metrics. These metrics give you visibility to the processing queue as well as the performance of runners and jobs. Enabling this feature is surprisingly easy. This post will show you how.

With the rise of OIDC, we no longer need to rely on secret keys or passwords to connect two services together. Instead, we can configure a trust relationship between the services and use that to securely request tokens for accessing resources. Adopting this approach can simplify things, but it can be scary for security teams and developers; they want to understand what makes this process work. In this post, walk through what’s happening under the covers.

It can be challenging too understand the differences between Azure DevOps and GitHub Actions. Sometimes, what you really need is a mapping of the features and terminology. Perhaps something annotated with how to support features that don’t have a direct equivalent. Perhaps something like this …

I’ve seen lots of teams trying to increase the availability of GitHub runners for their organization by implementing GitHub Actions Runner Controller (ARC). In some cases, they hope to try to exceed GitHub’s 99.9% SLA. Unfortunately, the math works against them. In this post, I’ll explain why.

One challenge with the GitHub’s Actions Runner Controller (ARC) is that it does not officially support Windows containers for the runners. With a little bit of work, though, it’s possible to make this configuration work on a hybrid Linux/Windows cluster.

Creating a well-organized build or release workflow is both an art and a science. Done properly, the process can be testable and maintainable, able to work on any CI/CD system. Like many things in software, there’s even a pattern that helps!

It’s not unusual for teams to want to merge the same branch into multiple branches. If they create multiple pull requests from that branch to each of the other branches, they suddenly find that their Checks behave differently than expected and the branches start to share results. Understanding why this happens makes it easy to get Checks to behave as expected.

Most package management systems support some kind of “universal artifacts” storage. Azure Artifacts supports “universal packages”, Artifactory supports “generic repositories”, and Nexus has “raw repositories”. But what about GitHub? From all appearances, it would seem this is an oversight. Although not explicitly documented, it turns out it’s fully supported.

If you’ve ever wanted to integrate an external system or execute parts of the CI process asynchronously, the GitHub Checks API can provide a way to make that happen. In fact, you can even use Checks to allow two workflows to work together, no waiting or polling from the runner required. Today I’ll demonstrate how the API works and provide two workflows that demonstrate how to build a working GitHub Check.