2026 : OpenClaw sur Mac Mini loué — API GitHub workflow_dispatch, chaîne batch nocturne, checkpoints et webhook d’échec avec backoff

Ce texte ne refait pas la narration « pipeline planifié + runner » du guide GitLab Scheduled Pipeline : ici le cœur est l’appel HTTP POST …/actions/workflows/<fichier>.yml/dispatches avec un corps JSON ref + inputs, ce qui fige une interface versionnée entre votre segment launchd et le graphe Actions.

L’intérêt pour l’hébergement marathon RunMini est double : d’abord vous cadrez les effets de bord (exports, appels API tiers, builds lourds) dans des jobs dont l’historique est public au sein du dépôt ; ensuite vous alignez le déclenchement sur une fenêtre APFS locale (typiquement entre une heure et cinq heures du matin) plutôt que sur l’horloge UTC implicite d’un on.schedule GitHub, souvent désynchronisée des créneaux où la machine louée respire encore après la journée SSH.

Croisez ce runbook avec la matrice planification 7×24, le fan-out cron, webhooks et backoff, et le volet heartbeat et dépannage pour que les daemons OpenClaw restent la source de vérité de disponibilité pendant qu’Actions ne s’occupe que de la cadence batch.

Jetons à moindre privilège

Le pire piège sur une machine partagée est un PAT classique trop large : tout script launchd devient alors un pivot latéral. Partez d’un PAT fine-grained limité au dépôt qui héberge le workflow, avec Metadata en lecture, Actions en écriture pour autoriser le dispatch, et Contents en lecture seulement si un job doit cloner des fragments privés.

Refusez les périmètres Administration ou Workflow tant que vous n’automatisiez pas la modification du YAML depuis le Mini ; pour la rotation mécanique, une GitHub App avec jeton d’installation reste plus propre qu’un PAT personnel partagé dans une équipe distribuée.

• Stockez le secret dans le Trousseau de session ou un fichier chmod 600 lu par un utilisateur service dédié, jamais dans le dépôt des playbooks OpenClaw.
• Documentez la rotation sur le même calendrier que les semver passerelle et rollback afin qu’une régression npm ne coupe pas le dispatch la même nuit.
• Testez le jeton depuis un poste admin avec un dry-run manuel avant de l’installer sur le bail : un 401 silencieux sur le Mini peut passer inaperçu jusqu’au rapport matinal.

Déclencheur cron et launchd

Sur macOS loué, launchd avec StartCalendarInterval reste la primitive la plus lisible pour une équipe qui suit déjà des plists OpenClaw : vous fixez des minutes précises, un ThrottleInterval pour éviter les rafales post-reboot, et des journaux sous ~/Library/Logs/OpenClaw/ ou un volume dédié NVMe.

Le script enveloppe curl avec un User-Agent explicite, lit le bearer depuis stdin ou variable d’environnement injectée par la plist, journalise le code HTTP et le corps tronqué en cas d’erreur client. Pour les environnements qui restent sur cron, reproduisez la même discipline mais vérifiez la tolérance du fournisseur aux dérives d’horloge après veille prolongée.

L’objectif n’est pas d’éviter GitHub : c’est de séparer la responsabilité « quand » (fenêtre locale, charge VNC/SSH documentée dans le centre d’aide) de la responsabilité « quoi » (nom du workflow, branche, inputs). Ainsi, un opérateur humain peut relancer la même interface via l’UI GitHub sans réécrire le cron.

Checkpoints idempotents

Les inputs batch_id, segment et force_rerun doivent être traités comme un contrat stable : côté Actions, des if: lisibles branchent sur ces champs ; côté Mac, un fichier dispatch.ckpt mémorise le dernier couple (batch_id, run_id) accepté.

Ajoutez un bloc concurrency: avec un groupe du type openclaw-night et cancel-in-progress: false pour empiler proprement deux dispatch accidentels plutôt que de tuer un job déjà en train d’écrire sur disque.

Politique simple : refuser un second envoi du même batch_id pendant trente minutes sauf force_rerun ; persistance recommandée sous un répertoire administré par le service (/var/db/openclaw/ ou équivalent documenté) avec sauvegarde atomique pour éviter les demi-écritures après coupure secteur.

curl -sS -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer ${GITHUB_DISPATCH_TOKEN}" \
  https://api.github.com/repos/OWNER/REPO/actions/workflows/nuit-openclaw.yml/dispatches \
  -d '{"ref":"main","inputs":{"batch_id":"'"$(date +%Y%m%d)"'","segment":"02","force_rerun":"false"}}'

Webhook d’échec et backoff

Les 429 et 503 GitHub ne sont pas des incidents applicatifs : programmez trois tentatives exponentielles avec jitter entre quelques secondes et une minute avant de basculer sur la voie d’alerte. Ne déclenchez pas la même logique que les sondes Guardian / health : ici l’échec est transport orchestrateur, pas indisponibilité du daemon OpenClaw.

Après épuisement du backoff, postez un JSON signé HMAC-SHA256 vers Slack ou un collecteur interne : dépôt, fichier workflow, code HTTP, extrait de réponse court, batch_id, fuseau du Mini. Exigez deux nuits consécutives en échec avant la page astreinte pour les seuls problèmes de transport, afin de ne pas confondre avec une régression modèle.

Gardez une copie locale du dernier payload échoué : lors d’un incident GitHub régional, cette trace permet de corréler rapidement avec les statuts publics sans rouvrir les secrets sur un canal large.

Chaîne minimale reproductible

1. Valider le YAML sur une branche de test : workflow_dispatch, inputs, concurrency, jobs qui appellent vos scripts ou runners self-hosted si besoin.
2. Merger sur main, créer le PAT fine-grained, enregistrer l’empreinte attendue du workflow dans votre runbook interne.
3. Installer la plist ou la ligne cron qui invoque le wrapper : lecture token, POST dispatch, backoff, mise à jour checkpoint, rotation des logs.
4. Comparer pendant une nuit pilote les horodatages launchd, les codes HTTP et l’URL du run GitHub ; ajuster la fenêtre si la charge VNC monte encore trop haut.
5. Brancher le webhook d’échec et forcer un scénario token révoqué en préproduction pour valider la signature et la déduplication côté récepteur.
6. Basculer en production, documenter la procédure de rollback : désactiver la plist + révoquer le jeton dans le même ticket de changement.

FAQ

workflow_dispatch remplace-t-il repository_dispatch ?

Pas nécessairement : repository_dispatch sert aux bus d’événements externes génériques ; workflow_dispatch expose des champs typés directement dans l’UI GitHub et se prête mieux à une checklist opérateur alignée sur batch_id/segment.

Puis-je combiner ce dispatch avec un schedule GitHub ?

Évitez deux horloges concurrentes sur le même workflow sensible : elles se marchent dessus sur les créneaux APFS. Choisissez soit le déclenchement Mini, soit le schedule GitHub, puis documentez l’unique source dans votre matrice planification.

Où héberger les artefacts lourds ?

Les artefacts Actions restent pratiques pour les preuves courtes ; pour les volumes importants, orientez vers un stockage objet et ne laissez sur le Mini que les chemins scratch documentés dans vos guides disque.