2026 OpenClaw auf gemietetem Mac Mini: GitHub API mit repository_dispatch — nächtliche Ereignisketten, Stillefenster und Backoff-Alarme

PAT mit Minimalrechten

Für POST https://api.github.com/repos/OWNER/REPO/dispatches genügt bei Fine-grained PAT typischerweise Metadata lesen sowie Contents lesen und schreiben auf genau einem Ziel-Repository. Das ist schmaler als viele workflow_dispatch-Setups, die Actions-Schreibrechte erfordern. Lebensdauer kurz halten, Secret mit chmod einschränken, Rotation mit Gateway-Upgrade-Checkpoints abstimmen.

Payload-Konventionen

Behandeln Sie client_payload als versionierten Vertrag. Pflichtfelder batch_id, segment, correlation_id und issuer erzwingen konsistente Logs auf dem Mac Mini und in GitHub Actions. Große Artefakte nur als Referenz übergeben.

on:
  repository_dispatch:
    types: [openclaw_nacht_a, openclaw_nacht_b]

Ketten-Statusmaschine

Modellieren Sie WARTE bis der Mini das Fenster bestätigt, dann SEGMENT_A, SEGMENT_B, ERFOLG oder FEHLER. Genau eine Instanz soll die nächste Transition per REST auslösen—entweder letzter Job mit PAT, gh api oder der OpenClaw-Router—sonst entstehen Wettläufe. Vertiefung: Multi-Szenario-Orchestrierung.

Nach erfolgreicher Validierung folgt ein zweiter Dispatch mit gleicher correlation_id. Bei Validierungsfehler einmaliger Alarm-Pfad ohne erneutes POST.

Stillefenster

launchd startet das Skript nur zwischen z. B. 01:00 und 05:00 Ortszeit; außerhalb beendet sich das Skript mit Null ohne GitHub API-Aufruf. Übersprungene Versuche in eine lokale JSONL-Warteschlange schreiben; OpenClaw sendet beim Öffnen des Fensters einen Digest statt vieler Einzelalarme—analog Daemon-Health-Webhooks.

Fehleralarme mit Backoff

Bei 429 immer Retry-After befolgen; bei 5xx exponentielles Warten mit harter Obergrenze und Jitter. Nach Budget-Erschöpfung signierter Webhook an OpenClaw mit batch_id und letztem Status—niemals das PAT. So bleiben Nachtaufgaben auditierbar.

curl und gh reproduzierbar

Zuerst vom Laptop testen, dann dieselbe Zeile in eine root-launchd-Hülle auf dem Mac Mini legen.

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/ORG/REPO/dispatches \
  -d '{"event_type":"openclaw_nacht_a","client_payload":{"batch_id":"20260424","segment":"a","correlation_id":"'"$(uuidgen)"'","issuer":"launchd"}}'

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

Fünf Umsetzschritte

1. YAML mit on.repository_dispatch.types für alle Segmente anlegen.
2. Fine-grained PAT erzeugen, auf dem Mini als Umgebungsvariable injizieren.
3. Ersten Dispatch per curl verifizieren, Lauf in der Actions-UI prüfen.
4. launchd-Plist mit Zeitfenster und Checkpoint-Datei aktivieren.
5. Webhook oder Collector-Endpunkt für Eskalation nach Backoff an OpenClaw anbinden.

Zitierfähige Leitplanken

• Fünf HTTP-Versuche mit exponentiellem Backoff als Startbudget vor menschlicher Eskalation.
• Vier Stunden Stillefenster als pragmatische APFS- und API-schonende Nachtbandbreite.
• Ein primärer Scheduler pro Knoten, niemals parallel cron und launchd für dieselbe Kette.

FAQ

Warum nicht nur workflow_dispatch?

Weil repository_dispatch maschinelle event_type-Ströme ohne Dateinamen in der URL bevorzugt und oft schmalere Tokens erlaubt.

Trifft dispatch immer den Feature-Branch?

Standardläufe folgen dem Default-Branch; planen Sie Test-Repos oder klar getrennte Workflows.

Welche Rolle hat OpenClaw?

Kanten-Orchestrierung: erster Aufruf, Checkpoint, Sammelalarm statt Chat-Spam.

Nächster Schritt: Dedizierten Apple-Silicon-Mac Mini für OpenClaw und repository_dispatch-Ketten mieten — Preise, kaufen.html ohne Anmeldung, Hilfe-Center für SSH/VNC, Blog für weitere Runbooks.