2026 OpenClaw MeshMac in der Praxis: Monorepo-Pfadfilter, inkrementelle Mehrknoten-Builds und Slack-Zusammenfassung — minimal reproduzierbare Schritte

Änderungserkennung: Pfadfilter für Monorepos

Starten Sie von einem stabilen Diff-Anker. In GitHub Actions genügt dorny/paths-filter oder ein kurzes Skript mit git diff --name-only "$BASE_SHA"...HEAD für die erste Version. Ordnen Sie jede geänderte Datei einer Paketwurzel zu — etwa apps/ios/** → apps/ios, packages/core/** → packages/core. Legen Sie die Zuordnung als YAML ins Repository, damit Reviewer falsche Negative vor Produktion erkennen.

Liefern Sie ein Artefakt für die Pipeline: JSON-Array wie ["apps/ios","packages/core"] oder Zeilenliste. Trifft der Filter nichts Kritisches, greifen Sie auf ein günstiges Smoke-Ziel statt einer Vollmatrix zurück. Mit Turborepo, Nx oder Bazel ersetzen Sie handgeschriebene Glob-Muster durch affected-Befehle — der Vertrag bleibt: nachgelagerte Schritte lesen eine normalisierte Plandatei, damit jeder MeshMac-Knoten dasselbe „was bauen“ interpretiert.

Schützen Sie main und Release-Branches strenger: Änderungen unter ci/** oder .github/** erweitern den Plan einmalig auf „alle mobilen Ziele“, danach wieder inkrementell. So vermeiden Sie stille Übersprünge bei Workflow-Edits. Parallele Worktrees und Lockfile-Konkurrenz auf demselben Rechner sind ein eigenes Thema — stimmen Sie Checkout-Strategie mit der Git-Worktree- und Lockfile-Matrix ab, damit Pfadfilter nicht gegen Package.resolved-Rennen arbeiten.

Warteschlange oder Sperre vor inkrementellen Builds

Inkrementelle Builds auf geteilten Macs brauchen trotzdem Zugangskontrolle. Zwei Jobs, die dieselbe Signaturidentität, Simulator-Caches oder eine CocoaPods-Sandbox anfassen, können sich gegenseitig beschädigen — auch wenn die Pfade verschieden sind. Wählen Sie ein Muster und dokumentieren Sie es:

• Zentrale Warteschlange — Worker ziehen Jobs aus Redis, RabbitMQ oder der in einheitlichem Deploy und Task-Queue-Sync beschriebenen OpenClaw-Task-Fabric; bei Xcode pro Lane einen Consumer.
• Kooperatives flock — Auf NFS oder freigegebenem APFS-Volume liegt /build-locks/ios.signing.lock; Builder nutzen flock mit Timeout. Recovery: Build-Warteschlange flock-FAQ.

Passen Sie die Sperre an Gateway-Rate-Limits und Session-Parallelität an, damit CI nicht zwanzig Sitzungen öffnet, während nur ein Signatur-Slot existiert.

OpenClaw erzeugt die Build-Zusammenfassung

Rohe CI-Logs sind laut; Slack ist kein Ort für zwölftausend Zeilen. Nach dem Build-Exit enqueuen Sie eine gateway-lokale OpenClaw-Aufgabe (oder ein deterministisches Template), die strukturierte Eingaben verarbeitet: Exit-Code, Liste gebauter Pakete, mesh_node_id, Wandzeit, erster fehlgeschlagener Test oder Compilerfehler. Ausgabe: unter etwa vierhundert Wörtern, Aufzählung der geänderten Pfade, Link zur Provider-Run-URL.

Übergeben Sie den Pfadfilter-JSON im Task-Kontext, damit die Zusammenfassung mit „Gebaute Pakete: …“ beginnt statt aus Logs zu raten. Bei xcresult-Bundles zeigen Sie OpenClaw auf die plist- oder JSON-Slices mit fehlgeschlagenen Tests, nicht auf das komplette xcodebuild-Transkript. Grüne Läufe können ein statisches Handlebars-ähnliches Template nutzen — vorhersagbare Latenz, wenn fünf Knoten in derselben Minute fertig werden.

Keine Geheimnisse in die Zusammenfassung: credential_id oder Jobname, keine Token. Für Notify-Felder und Dedupe-Keys siehe gemeinsames Build-Notify-Webhook-Layout, damit Slack später konsistent zu Teams oder Matrix bleibt.

Slack Incoming Webhook: kleinster praktikabler Berechtigungsumfang

Slacks klassischer Incoming Webhook ist eine einzelne HTTPS-URL für einen Kanal — bequem und riskant: wer die URL hat, kann spammen. Behandeln Sie sie als Bearer-Geheimnis: Dateimodus 0440, Owner root oder Gateway-User, Gruppe etwa openclaw, niemals im Git. Nur der OpenClaw-Gateway-Host liest sie und führt den POST aus — Runner schieben Ereignisse in die Gateway-Warteschlange.

Egress: hooks.slack.com (und ggf. Unternehmensproxy-SNI) allowlisten. Vom Gateway mit curl prüfen:

export SLACK_URL="$(sudo cat /etc/openclaw/secrets.d/slack/build-summary.url)"
curl -sS -X POST -H 'Content-Type: application/json' \
  -d '{"text":"MeshMac-Probe OK von '"$(hostname -s)"'"}' "$SLACK_URL"

Geheimnislayout und Rechte pro Knoten: Geheimnisse mit minimalen Rechten auf MeshMac-Knoten. Wachsen Sie über Incoming Webhooks hinaus, migrieren Sie zu einer Slack-App mit Bot-Scopes — behalten Sie die Single-Sender-Disziplin bei.

Fehler-Backoff (und wann nicht zu wiederholen ist)

Slack liefert gelegentlich 429 oder transiente 5xx. Wiederholen Sie mit exponentiellem Backoff, vollem Jitter und harter Obergrenze — fünf Versuche in etwa zwei Minuten ist ein gängiger Start. Praktisch: zufall(0, min(cap_ms, basis * 2**versuch)), damit synchronisierte CI-Runner nicht dieselbe Sekunde hammern. Retry-After respektieren, wenn Slack es setzt.

Nicht wiederholen bei 400 oder 404: JSON oder Webhook reparieren bzw. rotieren. Dedupe auf provider_run_id + Ergebnis mindestens 72 Stunden, damit flaky CI-Reruns nicht doppelt posten. Queue-Semantik: Task-Queue und Retry-Schritte.

Gateway & Token-Rotation — Kurztabelle

Steht das Gateway hinter einem Load Balancer, synchronisieren Sie Rotation und Health Checks mit Load-Balance und Failover-Schritten, damit drainende Knoten keine halben Slack-Zustellungen verlieren.

FAQ