2026 : Runner GitHub Actions auto-hébergé sur Mac distant pour OpenClaw CI — Webhooks lecture seule, pool de labels macOS et concurrence M4 (workflows Lobster + FAQ dépannage)

Si vous maintenez un fork ou un plugin OpenClaw, 2026 impose souvent deux pistes parallèles : la CI OpenClaw attend un vrai macOS pour macos-node, macos-swift et checks-node-compat-node22 ; en parallèle, les minutes macOS hébergées par GitHub et les files d’attente continuent de monter. Ce guide traite uniquement d’un runner macOS GitHub Actions auto-hébergé sur Mac distant dédié, du mapping des pools de labels macOS vers ces lanes, et de webhooks en lecture seule + workflows Lobster multi-étapes pour le triage des échecs — pas l’installation Gateway sur le port 18789, pas un shootout six régions (voir notre article régions & TCO runner). Tarifs : Tarifs Mac mini ; commande US Est / Ouest : US Est, US Ouest ; exploitation runner : centre d’aide.

1) Runners macOS hébergés vs Mac distant auto-hébergé : tableau de décision pour OpenClaw CI

Selon la documentation CI OpenClaw, macos-node exécute les tests TypeScript quand des sources liées à macOS changent ; macos-swift couvre lint/build/test Swift ; un workflow_dispatch manuel contourne le périmètre intelligent et lance tout le graphe (y compris la compat Node 22). En amont, le dépôt principal s’appuie sur des runners type Blacksmith macos-latest — acceptable pour le repo officiel, mais les mainteneurs de fork qui ne peuvent pas compter sur cette file ont besoin de leurs propres tags macOS.

Le macOS hébergé convient aux PR peu fréquentes ; l’auto-hébergement sur un M4 distant échange un loyer fixe contre des node_modules et DerivedData persistants — mieux pour un main quotidien, des shards de contrat plugin et des équipes qui veulent un pnpm check quasi local sur du matériel maîtrisé. Pour les nœuds multi-régions et le TCO jour–mois, lisez l’article régions & TCO ; ici nous ne branchons que les lanes OpenClaw. Le déploiement Gateway/agent de longue durée est traité dans le guide OpenClaw sur Mac distant (en une phrase : le Gateway gère chat/outils ; les runners CI gèrent compile/test).

Un autre signal : le job preflight du fork planifie systématiquement les lanes macOS à chaque toucher plugin, mais les runners hébergés vident les caches entre jobs — TypeScript et Swift passent plus de temps à télécharger qu’à tester. Un Mac distant avec store pnpm et DerivedData chauds réduit souvent le temps mur même à CPU comparable — mesurez sur votre dépôt avant de budgéter des sièges.

2) Checklist d’environnement : Xcode CLT, Node 22, isolation utilisateur CI

OpenClaw exécute la plupart des shards Node sur Linux, mais macos-node et checks-node-compat-node22 exigent Node 22 (voir la doc CI et la parité pnpm check locale). Sur l’hôte runner :

• Xcode Command Line Tools plus une version mineure Xcode figée par l’équipe ; la lane Swift exige Xcode complet, pas le CLT seul.
• Node 22.x via fnm ou mise dans le shell de l’utilisateur CI ; gardez actions/setup-node dans les workflows.
• pnpm aligné sur le packageManager amont ; cache sous le compte CI, pas votre compte dev quotidien.
• Utilisateur Unix dédié (ex. runner) pour actions-runner — distinct des secrets navigateur/chat.
• Plafonds ressources : surveillez memory_pressure ; ne parallélisez un second job sur 16 Go qu’après mesure.

API plateforme : Documentation Apple Developer ; politique Node : nodejs.org.

3) Enregistrement du runner et pool de labels macOS (HowTo)

Suivez le guide officiel des runners auto-hébergés. Pour un fork OpenClaw, mappez les jobs amont vers des labels explicites — pas un vague self-hosted seul.

# dans ~/actions-runner
./config.sh --url https://github.com/VOTRE_ORG/VOTRE_FORK \
  --token VOTRE_JETON_ENREGISTREMENT \
  --labels self-hosted,macOS,ARM64,openclaw-macos-node,openclaw-m4-16 \
  --name nuv-openclaw-macos-node-01

sudo ./svc.sh install
sudo ./svc.sh start

Pool de labels (par lane) :

• openclaw-macos-node — macos-node amont (chemins TypeScript/Vitest macOS).
• openclaw-macos-swift — macos-swift ; CPU/RAM plus lourds — évitez le parallèle par défaut avec node sur 16 Go.
• openclaw-node22 — optionnel pour compat dispatch ou smoke pnpm check local.
• openclaw-m4-16 / openclaw-m4-24 — palier matériel pour matrices et capacité.

jobs:
  macos-node:
    runs-on: [self-hosted, macOS, openclaw-macos-node]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test --filter macos-relevant

Pour signature/notarisation, ajoutez concurrency: { group: codesign-macos, cancel-in-progress: false } pour qu’aucun job ne déverrouille deux trousseaux à la fois. Notes SSH/runner : centre d’aide.

Runners org vs dépôt : un fork mono-dépôt peut utiliser un runner au niveau dépôt avec les labels ci-dessus. Si plusieurs plugins partagent une facturation, envisagez un runner d’organisation avec accès limité aux forks maîtrisés, et des groupes de runners (Enterprise) pour que les dépôts expérimentaux ne volent pas les machines Swift.

Mises à jour : épinglez la version de l’application runner dans votre runbook ; après chaque release GitHub, videz les jobs (./svc.sh stop), mettez à jour les binaires, redémarrez, confirmez l’état Idle avant de réactiver l’assignation auto. Les runners obsolètes expliquent souvent un « ça marche en local, pas en CI » quand le protocole de service change.

4) Brancher OpenClaw CI / dispatch et webhooks lecture seule

Gardez le preflight amont sur push/PR ; ne changez que le runs-on macOS vers votre pool. Pour une validation complète, utilisez le dispatch manuel documenté :

gh workflow run ci.yml --ref main
gh workflow run ci.yml --ref main -f target_ref=votre-branche -f include_android=true

Raisonnement webhook lecture seule (par phases) : pour le triage d’échec, abonnez-vous d’abord à des événements lecture seule — workflow_run.completed, check_run.completed, workflow_job.completed — et persistez les métadonnées (dépôt, branche, conclusion, URL). En phase 0, ne demandez pas l’écriture Contents ni l’auto-merge. Après vérification de signature, laissez les agents récupérer les URL de logs ou des scopes API Actions en lecture ; n’étendez vers commentaires/labels qu’avec une politique d’approbation.

À la réception, loguez seulement des champs stables : workflow_run.id, head_branch, conclusion, URL HTML de la run. Séparez les échecs de vérification HMAC des échecs d’auth pour distinguer secret mal configuré et replay. Si vous ajoutez Lobster, passez ces champs en stdin JSON — ne collez pas le corps webhook complet dans un prompt où un titre de PR malveillant pourrait influencer le choix d’outils.

5) Aide-mémoire concurrence M4 16 Go / 24 Go (pool mono-machine)

Repères pragmatiques pour les lanes macOS OpenClaw (pas un SLA ; fortement dépendant du dépôt). Pour des sièges ou régions supplémentaires, voir l’article TCO — pas de tableau six régions ici.

Nuvcloud propose du bare metal M4 multi-nœuds avec montées RAM/SSD — adapté aux sièges CI fixes. Disponibilité et tarifs : offres et pages de commande ; nous ne promettons pas de SLA de file dans cet article.

Pour dimensionner le SSD, budgétez trois courbes : DerivedData Xcode, store pnpm et répertoires de travail Actions sous _work/. Un SKU 256 Go peut suffire pour un fork lane node unique avec nettoyage deriveddata hebdomadaire ; les forks Swift lourds devraient viser 512 Go ou l’extension 1 To du configurateur tarifs. La pression mémoire sur 16 Go apparaît souvent comme des processus node tués pendant Vitest — si Console signale du jetsam, déplacez Swift vers un hôte 24 Go plutôt que de réduire les shards de test.

6) Workflow Lobster : triage reproductible des logs d’échec CI

Lobster condense des chaînes d’outils multi-étapes en un appel déterministe avec points d’approbation et resumeToken — idéal pour « CI rouge → récupérer logs → classifier → OK humain → publier résumé » plutôt qu’un LLM qui appelle des outils au hasard. Activez alsoAllow: ["lobster"] dans la config agent, puis lancez un pipeline.

{
  "action": "run",
  "pipeline": "exec --json --shell 'gh run list --workflow ci.yml --limit 5 --json databaseId,conclusion,headBranch' | exec --stdin json --shell 'gh run view $ID --log-failed' | exec --stdin json --shell 'node scripts/ci-triage-summarize.mjs' | approve --preview-from-stdin --limit 3 --prompt 'Publier le résumé sur le canal on-call ?'",
  "timeoutMs": 120000,
  "maxStdoutBytes": 512000
}

Découpez en fichier workflow .lobster : collect → classify → approval → notify (voir Lobster « workflow files »). Quand le statut est needs_approval, reprenez avec :

{
  "action": "resume",
  "token": "<resumeToken>",
  "approve": true
}

Habitudes de triage reproductibles : loguez pour chaque échec le run_id, le label déclencheur (ex. openclaw-macos-node) et un hash du premier bloc stderr dans le wiki d’équipe. Nettoyez le JSON Lobster avant publication sur les issues — des secrets fuient parfois dans les extraits de log. En timeout, augmentez timeoutMs ou séparez « fetch logs » et « résumé LLM ». Gardez une archive lecture seule 7 jours par run en échec pour distinguer flaky et vraie régression.

Beaucoup d’équipes gardent deux pipelines : un flux Lobster rapide qui classe seulement le type d’échec (Node vs Swift vs infra) et un flux lent qui récupère les logs complets après approbation humaine — comme la philosophie CI OpenClaw (preflight bon marché, lanes coûteuses seulement si besoin) — et évite de brûler des tokens LLM sur des runs vertes.

Si vous utilisez déjà gh en CI, le même scope PAT fonctionne sur l’hôte runner pour Lobster : limitez à actions:read et metadata:read en phase 0. Faites tourner le PAT au départ du personnel ; ne réutilisez jamais le jeton d’enregistrement runner comme credential API.

7) FAQ

Q1 : Le runner affiche Offline ?
Vérifiez launchd, expiration du jeton, disque plein. Retirez dans GitHub → Paramètres → Actions → Runners et relancez config.sh ; voir la doc runners auto-hébergés.

Q2 : macos-node se plaint de Node ?
Alignez Node 22 sur l’hôte, setup-node et checks-node-compat-node22 ; purgez les caches npm globaux obsolètes si besoin.

Q3 : Swift / SDK introuvable ?
Installez Xcode complet, sudo xcodebuild -license accept ; n’exécutez jamais macos-swift sur un hôte CLT seul.

Q4 : Webhook lecture seule bloqué en 403 ?
Vérifiez secret, TLS, chemin reverse-proxy, permissions d’événements App ; le gateway ne doit pas exécuter le corps de PR comme commande.

Q5 : openclaw doctor vs CI rouge ?
doctor = santé install/gateway ; les échecs CI vivent dans les logs Actions. Utilisez Lobster + gh run view, pas la doc onboard, pour déboguer un workflow.

Q6 : Peut-on ignorer macOS et ne faire que Linux ?
Oui pour des PR purement Node/doc, mais avant de merger des changements macOS/Swift lancez au moins un graphe workflow_dispatch complet ou vous divergez de l’intention preflight amont.

Q7 : Partager un runner entre amont et fork ?
Déconseillé — séparez groupes de runners et Secrets pour qu’un script de fork non fiable n’atteigne pas le matériel de signature amont.

Q8 : Lobster invalid JSON ?
Chaque étape du pipeline doit émettre du JSON en stdout ; augmentez maxStdoutBytes ; ne pipez pas des logs humains vers l’étape suivante sans --json.

Q9 : Mélanger hébergé et auto-hébergé ?
Oui — ex. PR sur hébergé, macos-swift sur main en auto-hébergé via if: ou workflows séparés.

Plus d’articles : index du blog. Pour la facturation multi-région et les sièges parallèles, continuez avec le guide régions & TCO runner macOS.