2026 : OpenClaw sur Mac Mini loué — API GitHub repository_dispatch, chaîne nocturne d’événements, fenêtre silencieuse et alertes à backoff

PAT et périmètre minimal

Un dispatch utilise POST https://api.github.com/repos/OWNER/REPO/dispatches. Avec un PAT fine-grained, limitez le dépôt d’automatisation, activez la lecture Métadonnées et accordez Contents en lecture et écriture sur ce dépôt seul. Cette combinaison suffit généralement au contrat REST sans distribuer Actions : write à chaque script — périmètre souvent nécessaire quand on centre tout sur workflow_dispatch dans le guide jumeau.

Si la conformité l’exige, préférez un jeton d’installation GitHub App avec le même périmètre « contenu » sur le dépôt cible et une rotation mensuelle. Stockez les secrets dans le trousseau de session ou une plist root, et alignez les rotations sur les jalons semver décrits dans upgrade et rollback passerelle OpenClaw.

• Ne réutilisez pas un PAT qui administre l’organisation ou publie des paquets.
• Séparez les dépôts lorsque le code applicatif et l’infra doivent rester isolés ; les dispatches inter-dépôts impliquent un second jeton — documentez-le dans le runbook.

Conventions de payload

Traitez client_payload comme un contrat versionné. Les équipes d’automatisation figent les clés obligatoires dès le début : chaque job peut alors les vérifier avec un petit schéma JSON ou un garde jq avant tout effet de bord réseau.

Exemple d’en-tête workflow écoutant deux segments :

on:
  repository_dispatch:
    types: [openclaw_night_a, openclaw_night_b]

Machine à états de chaîne

Modélisez le lot comme une machine explicite : EN_FILE (le Mac a accepté le créneau) → SEGMENT_A (premier dispatch délivré) → SEGMENT_B (dispatch suivant) → TERMINÉ ou ÉCHEC. Persistez le dernier batch_id et segment réussi sous /var/db ou le répertoire du service afin qu’un redémarrage ne rejoue pas des effets de bord.

La chaîne peut avancer de trois façons : un job final appelle l’API avec le PAT, un workflow réutilisable invoque gh api, ou le Mac interroge l’API Checks puis envoie l’événement suivant — choisissez un seul propriétaire d’horloge pour éviter les courses. Pour des vues d’ensemble plus larges, voir orchestration multi-scénarios OpenClaw.

1. Émettre openclaw_night_a avec un payload contenant next_event_type=openclaw_night_b comme indication, pas comme déclencheur automatique, tant que la validation n’a pas réussi.
2. En cas d’échec de validation, passer à ÉCHEC et n’emprunter le chemin d’alerte qu’une fois.
3. En cas de succès, poster openclaw_night_b en conservant le même correlation_id.

Fenêtre silencieuse

Concentrez le travail lourd sur disque APFS dans une bande locale calme (par exemple 01h00–05h00). La plist launchd n’invoque le script de déclenchement que dans cette bande ; hors fenêtre, le script sort en zéro sans appeler GitHub. Vous pouvez ajouter un garde côté workflow qui lit un fuseau TZ dans le payload et échoue vite si un opérateur lance un dispatch manuel en journée.

Lorsque le marketing ou le support chevauchent la nuit européenne, laissez OpenClaw mettre en buffer les tentatives ignorées : append JSONL dans une file locale, puis émettre un résumé unique des « envois supprimés » à la réouverture de la fenêtre — même esprit que les digests décrits dans les guides webhook et Guardian déjà cités.

Alertes d’échec et backoff

Entourez chaque appel HTTP d’un backoff exponentiel sur les réponses 429 et 5xx. Respectez Retry-After lorsqu’il est présent. Plafonnez le nombre total de tentatives (par exemple cinq) avant escalade. L’escalade doit être un webhook signé contenant batch_id, le dernier statut HTTP et un extrait tronqué du corps — jamais le PAT.

OpenClaw s’abonne à ce webhook, enrichit avec les dernières lignes des journaux du Mini, et n’ouvre un ticket que lorsque le budget de retry est épuisé : les tâches nocturnes ne pagent plus sur une panne GitHub transitoire.

Exemples curl et gh reproductibles

Exportez GITHUB_TOKEN ou placez un PAT fine-grained dans GH_TOKEN pour la CLI gh. Remplacez owner, repo et identifiants.

curl -sS -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/OWNER/REPO/dispatches \
  -d '{"event_type":"openclaw_night_a","client_payload":{"batch_id":"20260424","segment":"a","correlation_id":"'"$(uuidgen)"'","issuer":"launchd"}}'

gh api -X POST repos/OWNER/REPO/dispatches --input - <<'JSON'
{
  "event_type": "openclaw_night_b",
  "client_payload": {
    "batch_id": "20260424",
    "segment": "b",
    "correlation_id": "REMPLACER_PAR_UUID",
    "issuer": "openclaw_gateway"
  }
}
JSON

Validez d’abord depuis un poste de confiance (réponse vide avec code 204, run visible sous Actions), puis déplacez la même commande dans un wrapper launchd root sur le Mac Mini loué.

Guide pas à pas (HowTo)

1. Créer le PAT ou l’App, tester un POST manuel vers dispatches.
2. Ajouter les types YAML et fusionner sur la branche par défaut.
3. Verrouiller le contrat client_payload et un test jq dans le premier step.
4. Implémenter la transition A→B (curl, gh ou policy OpenClaw) avec le même correlation_id.
5. Brancher launchd sur la fenêtre silencieuse et écrire le fichier d’état batch.
6. Brancher l’escalade backoff → webhook signé → digest OpenClaw.

FAQ

Pourquoi ne pas tout faire en workflow_dispatch ?

workflow_dispatch optimise la sélection explicite de workflow et d’entrées UI. repository_dispatch optimise les flux machine avec event_type et des jetons souvent plus étroits lorsque l’écriture Actions n’est pas requise depuis le Mini.

repository_dispatch cible-t-il une branche précise ?

Les workflows s’exécutent en principe sur la branche par défaut ; prévoyez des dépôts ou fichiers distincts pour les expérimentations de branche feature.

Quel rôle pour OpenClaw si GitHub reste maître d’œuvre ?

OpenClaw reste l’orchestrateur de bord : il décide quand tirer le premier dispatch, persiste les checkpoints et agrège les webhooks pour qu’un humain ne lise qu’un résumé par lot.