Tbench AIActions
Client loginTry free

Actions / Mac execution

Your Mac. Two execution paths.

Use Docker Desktop for Linux CI, or evaluate the separate Apple-Silicon VM backend for native macOS and Xcode jobs. Each path has its own policy, installation and qualification record.

Device setup
Workflow overview4 steps

Keep the workflow you know

  1. Start with a repositoryPrivate code, approved scope
  2. Choose a compatible jobYour existing workflow steps
  3. Run on an enrolled deviceEligible capacity, or queued
  4. Inspect the resultLogs and reports on GitHub
push → queue → run → report
Execution flow

Linux CI on Intel and Apple Silicon.

Mac host source selects Linux x64 for Intel and Linux ARM64 for Apple Silicon, with native matching images and Docker Desktop resource limits. The currently published GitHub-worker bundle remains its immutable x64 release. The new Mac/ARM source is evaluated through a reviewed client pilot before a new download is published.

The independent tbench actions and tbench verify commands use separately approved policies and the local Docker engine. They never turn a Linux container into a native Xcode environment.

Independent runner guide

Native builds inside a disposable Apple VM.

The native source pilot uses our own Virtualization.framework host and guest helpers on Apple Silicon with macOS 14 or later. Each job gets a fresh image clone and machine identity. There is no guest network device, host directory share, clipboard, host shell fallback or signing-key injection.

The organization prepares a licensed, credential-free macOS baseline with its required Xcode and simulator versions. Tools and dependencies must already be present. The owner pins the image, helper and policy hashes outside the source checkout; a pull request cannot replace those approvals.

python -m infinity.native_macos doctor

python -m infinity.native_macos plan \
  --repo /absolute/project \
  --trusted-base <approved-base-sha> --head <exact-head-sha> \
  --policy-sha256 <approved-native-policy-sha256>

These commands inspect prerequisites and a plan; they do not boot a VM. An explicit run also needs a private owner configuration and reviewed guest image. Native cloud scheduling remains disabled while this local source pilot is qualified.

Qualify the client’s actual MacBook.

  1. Record Mac architecture, host and guest OS builds, Xcode version and exact helper, image, source and policy hashes.
  2. Run a real unsigned Xcode build and simulator test, then a deliberately failing test.
  3. Exercise cancellation, timeout, output overflow, parent termination, suspend/resume and interrupted image preparation.
  4. Confirm stopped-VM state, exact owned-file cleanup, unchanged baseline and no host or network access. Preserve ambiguous journals for inspection.

Hosted Swift compilation and protocol tests are part of the engineering gate. Physical VM execution, Xcode behavior and clean-machine installation are separate client-device checks.

Arrange the MacBook qualification

A branded, verifiable installation.

The native packaging framework prepares a branded Windows MSI and a universal Mac guide application, PKG and DMG for the GitHub worker. The independent CLI remains a separate engine and release.

Windows builds require an approved code-signing publisher certificate. Mac packages require Developer ID Application and Installer identities, notarization, stapling and Gatekeeper checks. Publication also requires independently approved installation and lifecycle evidence for the exact artifact hashes.

Installation never automatically enrolls a device or starts a job. Removing the package preserves runtime state, recovery journals and working repositories.

Review execution controls