Skip to content

MacOS Runners

Table of Contents

[TOC]

GitLab’s MacOS hosted runners have been a long-term goal spanning 5+ years. The current implementation uses AWS MacOS dedicated hosts after previous attempts with MacStadium that nearly reached GA but had fundamental flaws preventing full deployment.

All the MacOS fleeting hosts are dedicated hosts in AWS.

  • Runner Managers Location: Managed through Google Cloud Project gitlab-ci-155816

All MacOS runner environments follow the same architectural pattern:

  • saas-macos-staging: Production duplicate (M1) for testing all components (Account 251165465090)
  • saas-macos-medium-m1: Mac mini M1 machines for production workloads (Account 215928322474)
  • saas-macos-large-m2pro: Mac mini M2 Pro machines for resource-intensive jobs (Account 730335264460)

img.png

  • AWS MacOS Dedicated Hosts: Bare metal Mac mini machines running in AWS
  • MacOS Virtualization Framework: Direct job VM management (replacing Tart after licensing changes)
  • Tart: Still used for building job VM images (not for runtime)
  • Packer: Automated AMI building
  • Ansible: Tool installation and configuration

For general information on the projects that are used to maintain runners, including MacOS runners, refer to the projects overview.

  • Nesting

    • gRPC server providing RPC API for job VM creation
    • Integrated into gitlab-runner
  • Fleeting AWS Plugin

    • Manages auto-scaling groups for AWS
    • Requires Terraform setup with ARN/credentials

The infrastructure is defined using Terraform configurations located in the config-mgmt repository:

MacOS has a distinct process for building images for both host machines and job VMs.

Refer to access.md for information on how to access MacOS instances and job VMs.

Refer to debugging.md for a playbook on debugging issues with AWS MacOS runner instances.

Refer to resources.md for information on the available AWS resources.