De plus en plus d’équipes veulent un seul Mac mini M4 distant bare metal à Singapour, Tokyo, Séoul, Hong Kong, US East ou US West pour la CI Xcode et les runners auto-hébergés GitHub Actions le jour, puis prêter la même machine à OpenClaw ou un autre agent IA la nuit. L’échec vient rarement de « peut-on installer les deux piles ? » mais de la contention des ports simulateur, de l’inflation des files et du mélange Keychain entre identités de signature et jetons de bot. Ce guide fournit une matrice Go/No-Go de capacité, trois modèles de fenêtres horaires, un runbook de rollback en sept étapes et un tableau de paliers pour savoir quand séparer les machines. Tarifs : page tarifs NOVAKVM ; commande : page commander ; politique d’accès : centre d’aide. À lire avec runners GitHub Actions distants et playbook OpenClaw multi-workspace.
À la fin vous devez trancher sans débat : quand le prêt est interdit ; comment pic en semaine, batch nocturne et semaine de gel release diffèrent en labels ; comment revenir en arrière avec profondeur de file et métriques de base ; quand passer en M4 Pro ou en nœuds parallèles dans la même région plutôt qu’en colocation forcée. Vérifiez la sémantique des runners et le comportement du Gateway OpenClaw dans la documentation officielle après chaque release amont.
[ SECTION_01 ] // PAIN_POINTS Cinq pièges quand CI et agents IA partagent un Mac distant
Propriété floue : les mainteneurs CI et les opérateurs d’agents modifient chacun les labels du runner, mais personne ne signe la fenêtre de prêt — les agents gardent les simulateurs chauds aux heures de pic PR. Mauvaise lecture de la file : on croit que « il y a plus de jobs » alors que l’hôte est saturé ; un label macos-ci supplémentaire peut faire passer l’attente médiane d’environ douze minutes à plus de trente-cinq. Fuite d’environnement : un utilisateur macOS et un Keychain pour Archive et tokens de canal laissent une config à moitié finie après la fenêtre.
Épuisement simulateur et ports le matin après une longue session agent : WebDriver multi-instances ou appareils XCTest bloqués donnent « device busy » sur la matrice suivante. Décalage de location : un mois de M4 Pro pour « tester la colocation », puis payer longtemps pour une double charge après la semaine de pic.
- Dérive des labels : les tags
macos-cientrants restent actifs pendant le prêt agent. - Zéro standby : sans second runner in-region, le prêt est un point unique de défaillance.
- Runs agent sans borne : jobs multi-jours sans checkpoints remplissent le volume système.
- Credentials partagés : clés modèle, tokens canal et certificats CI dans un même répertoire bloquent le rollback.
- Écritures en gel : l’agent signe ou écrit en base pendant la semaine de freeze release.
La colocation tient quand on la traite en fenêtres horaires + labels + isolement des credentials, pas en « éteignant la CI la nuit ».
[ SECTION_02 ] // LENDING_MATRIX Matrice Go/No-Go de prêt et trois modèles de fenêtres
Avant de passer l’hôte du mode CI au mode prêt agent, appliquez le portillon ci-dessous. Toute ligne de la colonne stop impose de suspendre le prêt ou d’ajouter du standby.
| Signal | Go (prêter) | No-Go (pause) |
|---|---|---|
| Runner standby in-region | ≥1 hôte pour smoke et hotfix | Aucun backup ; prêt = risque de coupure |
| Profondeur de file | ≤ médiane historique × 1,2 | >1,5× médiane pendant deux heures |
| Budget durée agent | ≤90 minutes avec checkpoints | Sans plafond ou occupation multi-jours |
| Isolement credentials | Utilisateur séparé ou partition Keychain | Fichiers signature et API partagés |
| Gel release | Agent lecture seule (pas d’écriture ni signature) | Semaine de gel avec chemins write/sign |
Trois modèles de fenêtres (adaptez les heures au fuseau principal de l’équipe ; exemple UTC+8 en semaine) :
| Modèle | Plage | Labels CI | Agent |
|---|---|---|---|
| Blindage pic semaine | 10:00–19:00 | CI complète ; pas de prêt | Arrêt ou healthchecks lecture seule |
| Tranche batch nuit | 23:30–06:00 | Retirer les tags macos-ci entrants |
Prêt autorisé ; plafond 90 minutes |
| Semaine gel release | ±7 jours autour du ship | Archive et notarisation seules | Lecture seule ; pas de write-back canal |
[ SECTION_03 ] // RUNBOOK Rétrécissement des labels Runner, vidage et rollback en sept étapes
Prêter la machine est un changement auditable, pas une commande unique « arrêter les services ». Les étapes lient labels, file, métriques et rollback pour que la CI ne schedule pas dans un hôte sale après l’agent.
- Ouvrir un ticket de changement : hostname, fenêtre de prêt, owners CI et agent ; semaines de gel avec double validation.
- Prouver le standby : smoke sur un second runner in-region capable de prendre les PR urgentes.
- Rétrécir les labels entrants : retirer
macos-ci(et pairs) au niveau org ou dépôt. - Vider les jobs en cours : attendre selon le SLA ; ne pas tuer Archive ou notarisation.
- Capturer la baseline : profondeur de file, jobs actifs, charge CPU, espace libre sur le volume système.
- Exécuter le prêt : démarrer l’agent (ex. OpenClaw Gateway) ; surveiller pente disque et occupation simulateur.
- Rollback : arrêter l’agent, restaurer les labels, relancer le smoke ; si file > baseline ×1,3, reporter le prochain prêt.
#!/bin/bash
RUNNER_NAME="${1:-novakvm-m4-sg}"
gh api "repos/${GITHUB_REPOSITORY}/actions/runners" --jq \
".runners[] | select(.name==\"$RUNNER_NAME\") | .labels[].name"
test -z "$(gh api ... | grep -c macos-ci)" && echo "CI_LABELS_OFF"
Les labels des runners auto-hébergés et le comportement des files sont définis par la documentation GitHub. Rouvrez le lien après chaque changement amont.
Résidence et redémarrage du Gateway OpenClaw selon le dépôt du projet.
https://github.com/openclaw/openclaw
[ SECTION_04 ] // CONFIG_REGION Paliers M4, six régions et quand séparer les hôtes
Quand pics CI en semaine et agents nocturnes exigent tous deux un SLA, une seule machine touche d’abord la RAM et les pools simulateur. Le tableau sert de guide de frontière, pas de fiche marketing.
| Palier | Pic CI | Agent nuit | Recommandation |
|---|---|---|---|
| M4 16 Go / 256 Go | 1–2 lanes légères | Lecture seule ou <30 minutes | Éviter agent complet toute la nuit |
| M4 24 Go / 512 Go | 3–4 lanes modérées | ≤90 minutes avec checkpoints | Séparer pools simulateur et DerivedData |
| M4 Pro 64 Go / 2 To | Archive + tests parallèles | Multi-workspace / pics canal | Toujours splitter ou paralléliser en gel release |
| Parallèle même région | Hôte CI dédié | Hôte agent dédié | Supprime le risque de bascule prêt/rollback |
Affinité six régions : rapprocher runners, stockage d’artefacts, allers-retours API modèle et cibles d’intégration. Singapour pour l’Asie du Sud-Est ; Tokyo et Séoul pour l’astreinte Est asiatique ; Hong Kong pour le debug interactif Sud-Chine ; US East et US West pour les habitudes Atlantique et Pacifique. Locations jour et semaine suffisent pour un cycle prêt→rollback ; passer au mensuel quand la pente de file se stabilise ; ajouter des nœuds parallèles pour les semaines de pic.
[ SECTION_05 ] // DATA_FAQ Métriques citables, FAQ et mise en œuvre bare metal
Les chiffres ci-dessous sont des fourchettes de revue d’ingénierie pour capacité et location — pas des benchmarks vendeur.
- Amplification de file : sur hôte saturé, des labels runner supplémentaires peuvent faire passer l’attente P50 d’environ 12 minutes à 35+ minutes.
- Plafond prêt agent : sans checkpoints, rester ≤90 minutes pour ne pas empoisonner le jour CI suivant.
- Délai de changement : annoncer prêt et gel 24–48 heures à l’avance et garder un créneau de rollback.
- Redondance standby : au moins un runner in-region capable de smoke — sinon prêt sans marge.
- Déclencheur rollback : file post-prêt > baseline × 1,3 → prochain prêt bloqué jusqu’à cause racine levée.
FAQ
- Q : CI le jour, OpenClaw la nuit ? R : Oui si la matrice Go/No-Go passe et que rétrécissement des labels + rollback en sept étapes sont exécutés.
- Q : La file est déjà longue — peut-on prêter ? R : Non. Réduire les lanes ou ajouter du standby d’abord.
- Q : Semaine de release ? R : Agent lecture seule ; Archive et notarisation monopolisent la machine ; pas de signature ni écriture DB par l’agent.
- Q : Une location jour suffit-elle ? R : Oui pour un cycle complet prêt→rollback ; colocation stable : plutôt semaine puis mois.
Les clouds Mac virtualisés partagés cassent souvent les fenêtres de prêt par voisins bruyants et maintenance opaque. Un portable de service à côté de la CI hérite du sommeil, des résidus simulateur locaux et d’un rollback non auditable. Les équipes qui veulent une CI iOS/macOS de jour et des agents IA de nuit sur Apple Silicon dédié — avec nœuds six régions et échelons de location — aboutissent souvent plus proprement sur la location Mac mini bare metal NOVAKVM : hôtes exclusifs, runners routés par labels, parallélisme in-region, du « test agent une nuit » à la « semaine release sans interférence ». Avant le prochain changement, collez la table Go/No-Go et le rollback en sept étapes dans le même ticket — cela vaut mieux que débattre si la CI doit « simplement rester éteinte la nuit ».