OpenClaw in die CI zu bringen bedeutet drei Fragen: wer triggert, wo läuft es, wie authentifiziert es sich. GitHub-gehostete macOS-Runner und Self-hosted Runner auf MacCloud können koexistieren—erstere für leichte Schritte, letztere, wenn Disk, Kexts oder Dienste sensibel sind.
1. Trigger: nicht jeden Push voll laufen lassen
Lange Jobs per workflow_dispatch oder Zeitplan; für PRs Pfadfilter nutzen. OpenClaw-Schritte in einen eigenen Job legen, damit sie nicht ständig in einer generischen Lint-Matrix abbrechen.
2. Geheimnisse, Tokens, Audit
Produktionsgeheimnisse in GitHub Environments mit Required Reviewers. Für MacCloud- oder Ticket-APIs kurzlebige Tokens mit Rotation—nie im Repo hardcoden. Audit-Logs müssen „welcher Run welches Credential nutzte“ rekonstruieren.
3. Self-hosted Runner auf MacCloud
Nach Registrierung auf einem dedizierten Mac eigene Labels für OpenClaw-Jobs setzen (z. B. runs-on: [self-hosted, macOS, openclaw]) und von generischen iOS-Build-Queues trennen. Vor Wartung oder OS-Upgrade Runner in GitHub deaktivieren, damit halb aktualisierte Maschinen keine Jobs ziehen.
4. Cache, Artefakte, Logs
Große Dependencies über Actions Cache oder interne Artefakt-Registry; Logs/Reports als Artefakte hochladen. Cache-Keys müssen Lockfile-Hashes enthalten, damit keine veralteten Dependencies als aktuell gelten.
5. Fehlerausbreitung begrenzen
Timeouts und Retry-Limits für OpenClaw-Schritte; bei Auth-Fehlern oder Quota-Ende sofort failen und labeln, statt endlos die Queue zu blockieren. Backoff wie in Automatisierungsszenarien.
6. Checkliste
- Trigger decken Default-Branch, PRs, manuell ab?
- Environment-Schutz blockiert unreviewte Fork-PRs?
- Runner-Labels passen 1:1 zur Job-Matrix?
- Artefakt-Logs mit ausreichender Tiefe?
Bei Mischbetrieb mit Runnern erneut MacCloud-Praxis lesen: Disk, Graceful Shutdown, Billing-Grenzen.
