On-Demand GitHub Actions Mac Runners with Orka

Introduction to the new and improved dedicated Apple GitHub integration for Orka 

You asked, and we answered.  

Over 100 million developers use GitHub, including many, many iOS developers. We have good news for those developers using both GitHub Actions and Orka – there's a new GitHub Actions integration that automates the creation of ephemeral runners on Orka VMs.  

The prior version of our GitHub Actions plugin with Orka was script-based, and users could deploy an Orka VM and configure it as an agent. We refer to this as the static in-cluster approach. While it is useful for teams who want to have VMs consistently running and waiting for jobs, we found that numerous customers wanted to dynamically deploy VMs as needed for jobs, allowing for more flexible use of compute resources throughout the cluster. We addressed this need with a new integration that now allows users to dynamically spin up and down runners based on CI demand with ephemeral runner creation and autoscaling capabilities.

How to setup GitHub Actions + Orka integration 

The new ephemeral runner offers flexibility, by dynamically spinning VMs up and down as required. This results in a reduction resource consumption within the cluster, as there’s no need to allocate resources on K8s nodes for Action Runner Controller (ARC) pods. We refer to this as an out-of-cluster approach. The out-of-cluster setup also keeps user information secure, as users don’t have to submit GitHub or agent credentials to MacStadium. 

One aspect to keep in mind when using the GitHub Actions runner integration out-of-cluster is that it requires users to run the Orka Actions Runner (OAR) on a machine that has connectivity to the Orka environment.

Dev recommendation – Our team of Orka experts recommends the out-of-cluster setup for top-notch flexibility, as well as a clear separation of responsibilities.

How to use the GitHub Actions Mac integration 

Here’s the general workflow for an our-of-cluster approach: 

1. Users run the provided OAR app on their machines, typically as a Docker image.

2. A config file allows users to specify GitHub info → credentials and repo information, Orka cluster info, runner info, and agent info.

3. The OAR then authenticates with the GitHub API and proceeds to: 

• Register the designated number of runners as specified in the configuration. 
• Initiate listening for messages from each runner.

4. Once the user triggers a build on a runner monitored by the OAR, a message is sent to the OAR. On receiving a JobStarted message, the OAR takes the following steps: 

• Creates and ensures the existence of an Orka VM for the reported job. 
• Generates a VM name, possibly based on workflowId + retryNumber + job display name. 
• Creates the VM using the provided configuration information, including VM config, image, and CPU. 
• Establishes an SSH connection to the VM. 
• Generates a Just-In-Time (JIT) Configuration and transmits it to the VM via the SSH connection. 
• Downloads the GitHub agent version specified in the configuration. 
• Utilizes the JIT config and registers the agent on the VM. 

If you need another way to configure GitHub Actions and Orka, you can try the in-cluster approach. For more information about setting up GitHub Actions runners on Orka, check out our technical docs. 

Tl;DR 

The new GitHub Actions integration dynamically creates ephemeral GitHub runners on Orka VMs using an out-of-cluster approach. Whether you use an existing static in-cluster approach or this new dynamic out-of-cluster approach, you can reap the benefits of using GitHub Actions and Orka. 

Discover what else you can connect with Orka, or chat with an Orka expert today! 

Read the GitHub Actions Integration technical documentation here.