Registra il tuo runner in 10 minuti

La tua macchina si trova su una rete Tailscale privata e non su internet pubblico. Quindi non c’è nessuna porta SSH aperta da scoprire e niente da mettere in sicurezza. Per entrare servono due cose, una volta sola.

Installa Tailscale da tailscale.com/download e accedi. È gratuito per uso personale e per le dimensioni di account che servono qui alla maggior parte dei team. Funziona su macOS, Linux e Windows. Poi accetta l’invito di condivisione che ti inviamo quando la macchina è pronta. Ti dà accesso a quella sola macchina e a nient’altro sulla nostra rete.

Il tuo portale mostra il comando esatto, con l’indirizzo della tua macchina già inserito:

ssh runner@100.x.x.x

Non ci sono password o chiavi da gestire: l’autenticazione la fa Tailscale. Se il tuo account Tailscale usa un’email diversa dal tuo indirizzo di fatturazione, richiedi una condivisione per quell’email nel portale.

I tuoi job CI non hanno bisogno di Tailscale. GitHub Actions raggiunge il runner tramite la connessione in uscita di GitHub stesso. Questo serve solo quando vuoi una shell sulla macchina.

Per la CI basta SSH. Quando un log non basta, la stessa macchina è raggiungibile in condivisione schermo sulla stessa rete privata. Così Instruments, il Simulator e l’interfaccia di Xcode funzionano come in locale. Il portale mostra l’indirizzo, l’utente runner e una password unica per il tuo noleggio.

Su un Mac, apri Finder, poi Vai → Connessione al server (⌘K):

vnc://100.x.x.x

Su Windows, installa RealVNC Viewer o TightVNC e collegati a 100.x.x.x:5900. Su Linux funzionano sia Remmina sia TigerVNC, con lo stesso indirizzo. Se il client chiede solo una password, lascia vuoto il nome utente.

È la cosa che la maggior parte dei servizi CI non sa fare. Un runner ospitato ti dà i log e nient’altro. Così un crash che si riproduce solo sotto Instruments è un crash che non puoi analizzare.

Nel tuo repo (o nella tua org) vai su Settings → Actions → Runners → New runner. GitHub mostra un token monouso. Lo incollerai nel comando qui sotto. I runner a livello di org sono condivisi tra tutti i repo dell’org.

Entra in SSH come sopra, poi esegui il comando di configurazione dal portale (inserisce già l’etichetta della tua macchina):

cd ~/actions-runner
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO \
  --token <RUNNER_TOKEN> \
  --labels self-hosted,macOS,macrun-unit-01 \
  --unattended

# start it as a service (survives reboots)
./svc.sh install && ./svc.sh start

Il demone runner-agent tiene attivo questo servizio in automatico. Se va in crash, viene riavviato entro 30 secondi.

Fai puntare il tuo workflow sul runner. Ecco tutta la modifica:

 jobs:
   build:
-    runs-on: macos-latest
+    runs-on: [self-hosted, macOS, macrun-unit-01]

Tutto il resto della pipeline resta esattamente uguale.

Le release recenti di Xcode sono preinstallate e fissate tramite xcodes. Scegline una nel tuo job, oppure richiedi una nuova versione dal portale (di solito in giornata):

- run: sudo xcodes select 26.6
- run: xcodebuild -version

La macchina è tua, quindi le cache restano sul disco locale tra un’esecuzione e l’altra. Niente costo di download ripetuti. Percorsi comuni:

~/Library/Developer/Xcode/DerivedData   # build cache
~/Library/Caches/CocoaPods              # pods
~/.gradle  ~/.npm  ~/.gem               # toolchain caches
~/Library/Caches/org.swift.swiftpm      # SwiftPM

Puoi comunque usare actions/cache se vuoi chiavi di ripristino deterministiche. Ma per la maggior parte delle build iOS il vantaggio vero è il disco locale già caldo.

Riavvia, richiedi versioni di Xcode e gestisci la fatturazione dal tuo portale. Ti serve altro? Rispondi a qualsiasi email di MacRun e ti risponde una persona.