Kurzfassung: JetBrains TeamCity sendet per HTTP-Webhook (Build Feature, Meta-Runner oder kontrollierter Skriptschritt) ein kleines JSON an Ihre öffentliche HTTPS-URL; dahinter läuft auf einem Remote-Mac ein OpenClaw-Gateway auf 127.0.0.1 mit Bearer- oder HMAC-Prüfung. Der Handler führt Abhängigkeits-Preflight (npm ci --dry-run, composer validate usw.) und einen Lockfile-Drift-Scan aus und postet eine kurze Build-Zusammenfassung zurück an die TeamCity-REST-API — mit Backoff 2/4/8 s und klaren Logs. Dieses Tutorial folgt docs.openclaw.ai für Node 22+/24 LTS, openclaw onboard, openclaw doctor und openclaw onboard --install-daemon sowie Gateway-Health. Vertiefung: Jenkins Generic Webhook & Preflight, CircleCI-Webhook & Lockfile und LaunchAgent-Healthcheck.

Warum Remote-Mac als CI-Vorknoten? Dedizierter Apple-Silicon entkoppelt git fetch und Registry-Last von geteilten TeamCity-Agenten: reproduzierbare Latenz, NVMe-Workdirs, 24/7 — sinnvoll bei Rechenzentrums-Split und stabilem Egress zu Git/Artefakten.

SchichtAufgabePraxis-Hinweis 2026
TeamCityPOST mit buildId, Branch, RevisionHTTP-Timeout > p95-Preflight + TLS-Marge
TLS-Reverse-ProxyTerminierung, Rate-Limits, Request-IDsAuthorization nicht strippen
OpenClawValidierung, Skills, LogsSchnelles 2xx/202, schwere Arbeit async
TeamCity RESTKommentar / Problem / StatusPAT nur Projektbereich, kein Global-Admin
  • TeamCity-Timeout zu knapp: Der Server bricht den ausgehenden POST ab, obwohl der Mac noch korrekt arbeitet — messen Sie p95 und addieren Sie 30–60 % Puffer oder nutzen Sie 202 Accepted plus Hintergrundjob.
  • Lockfile grün, Build rot: falscher Referenz-Commit oder andere Registry-Kette als im Agent — git fetch und Diff gegen dieselbe VCS-Root wie TeamCity.
  • launchd ohne Toolchain: npm in SSH vorhanden, im Daemon nicht — absolute Pfade oder env-Datei in der LaunchAgent-Plist.

Installation, Node, openclaw onboard --install-daemon

Node 22+ bzw. 24 LTS; npm i -g openclaw@latest; openclaw doctor bis grün. Für Dauerbetrieb: openclaw onboard --install-daemon → typisch LaunchAgent. launchd hat nicht dieselbe PATH-Semantik wie die SSH-Shell — NODE_BINARY, PATH, optional NODE_EXTRA_CA_CERTS in der Plist setzen; mit sudo -u … which node prüfen.

Gateway-Port und Health: Beispielport in der Doku oft 18789; effektiven Wert in openclaw.json lesen. openclaw status, openclaw status --deep, openclaw health laut Doku; ergänzend Loopback-/health mit demselben Bearer wie das Dashboard.

curl -sS -o /dev/null -w '%{http_code}\n' \ -H 'Authorization: Bearer YOUR_GATEWAY_TOKEN' \ --connect-timeout 3 --max-time 10 \ http://127.0.0.1:PORT/health
  • Dienstbenutzer: eigener macOS-Account für OpenClaw, Schreiben nur für Logverzeichnis und temporäre Workdirs — kein breites sudo.
  • TeamCity-Seite: dedizierter Benutzer oder PAT nur mit Rechten für Lesen der Ziel-Builds und REST für Kommentar/Status — keine Server-Administration.
  • Geheimnisse: Gateway-Token, Webhook-Shared-Secret und TeamCity-PAT in Dateien chmod 600 oder Secret-Store; nie Klartext in TeamCity-Parameter-UI ohne eingeschränkte Sichtbarkeit.

TeamCity: PAT mit kleinstem Umfang & ausgehender Webhook

PAT/Service-User nur für Ziel-buildType und benötigte REST-Pfade (Kommentar/Problem o. Ä.) — kein globaler Server-Admin. Webhook: Plugin, Build-Feature oder früher Schritt mit curl; klären, ob der POST vom TeamCity-Server (Firewall!) kommt.

JSON-Minimum: buildId, buildTypeId, branchName, revision, optional webUrl. Authorization: Bearer … plus optional HMAC auf Roh-Body (X-Signature).

curl -sS -X POST 'https://ihre-domain.example/openclaw/teamcity' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer GATEWAY_SHARED' \ -H 'X-Signature: sha256=…' \ --data '{"buildId":"12345","buildTypeId":"Projekt_CI","branchName":"main","revision":"abc1234"}' \ -w '\nHTTP %{http_code}\n'
Token-Matrix (vereinfacht)
  • Eingehend (Mac): statischer Bearer oder HMAC — rotieren ohne Commit ins Git.
  • Ausgehend (Mac → TeamCity): PAT/Basic nur für REST-Pfade, die Sie wirklich beschreiben.
  • Dashboard: separates OpenClaw-Dashboard-Token, nicht mit Webhook-Secret mischen.

Gateway, TLS, Bearer-Validierung

Der eigentliche OpenClaw-Prozess sollte nur auf 127.0.0.1 lauschen; TLS endet am Reverse-Proxy. Ihr Handler prüft zuerst den statischen Bearer und optional HMAC über den Roh-Body — konstantzeitiger Vergleich, keine Secrets in stdout. Nach erfolgreicher Prüfung antworten Sie innerhalb weniger Sekunden mit HTTP 200 oder 202 und übergeben Clone, Resolver und Lockfile-Scan an eine Queue, einen Worker oder ein OpenClaw-Skill. Warten Sie im selben Request auf Minuten-Preflights, bricht TeamCity den ausgehenden Aufruf mit Socket timeout ab, obwohl der Mac im Hintergrund noch arbeitet.

Bewahren Sie den Roh-Body (Buffer) vor dem JSON-Parse; so bleibt eine spätere Signatur-Erweiterung möglich. Für Unternehmens-CA: NODE_EXTRA_CA_CERTS setzen und curl -v vom TeamCity-Server aus gegen Ihre öffentliche URL fahren.

Webhook-Validierung: Prüfplan vor Produktion

  • 1. Beispiel-JSON wie von TeamCity gesendet speichern; mit curl und korrektem Authorization gegen Staging-URL senden und Parser/Signatur testen.
  • 2. Einen echten Build mit Testprojekt auslösen; buildId in TeamCity-Server-Log, Proxy-Access-Log und Mac-Anwendungslog vergleichen.
  • 3. Absichtlich falsches Secret: muss 401 liefern, ohne Nebenwirkungen; TeamCity soll den Schritt als fehlgeschlagen markieren oder retry-fähig konfiguriert sein.
  • 4. Zeit vom ersten Byte bis Antwortende messen — Ziel: nur Auth + Enqueue, typisch <2 s, bevor schwere Shell startet.

Preflight, Lockfile-Drift und Workdir pro Build

Viele Teams führen einen leichten Preflight bereits in TeamCity aus; der Mac wiederholt ihn als „truth layer“ mit derselben Toolchain-Version wie Ihr OpenClaw-Stack. Nutzen Sie WORKDIR=$(mktemp -d), shallow clone, Checkout exakt auf revision aus dem Webhook. Typische Befehle:

npm ci --dry-run composer validate --no-check-publish composer install --dry-run --no-interaction --no-ansi

Für Lockfile-Drift z. B. git fetch origin && git diff --exit-code origin/main -- package-lock.json pnpm-lock.yaml composer.lock — Exit-Code 1 bedeutet Drift. Private Registries: COMPOSER_AUTH bzw. npm_config_//… in der LaunchAgent-Umgebung setzen, nicht in der TeamCity-UI loggen. Parallelität: pro buildId ein Workdir oder Repo-weises File-Lock, sonst überschreiben sich Klone und der Scan lügt.

Zahlen, die im Runbook stehen sollten
  • Health-Intervall: z. B. 60 s Loopback-/health, Alarm nach drei Fehlschlägen in Folge.
  • Preflight-Cap: Shell-Timeout 300–600 s für Hintergrundjobs auf dem Mac.
  • Summary-Größe: JSON-Feld summary unter ~2 KB, Rest im Logfile.

Schritte-Checkliste (minimal reproduzierbar)

  1. Node 22+ bzw. 24 LTS installieren; npm i -g openclaw@latest; openclaw doctor grün.
  2. openclaw onboard durchlaufen; openclaw onboard --install-daemon oder LaunchAgent; PATH/NODE_BINARY in Plist angleichen.
  3. Gateway nur 127.0.0.1; TLS-Proxy; curl auf /health mit Bearer wie in der Doku.
  4. TeamCity-PAT mit kleinstem Umfang erzeugen; in Mac-Umgebung als Datei 600 ablegen.
  5. Webhook/HTTP-Schritt konfigurieren: JSON mit buildId, revision, Bearer/HMAC, Timeout > p95-Preflight.
  6. OpenClaw-Handler: Auth → optional 202 → Clone → Preflight + Lockfile-Diff → Log nach ~/Library/Logs/… mit buildId-Präfix.
  7. REST-Callback an TeamCity: kompaktes JSON/Kommentar; Backoff 2 / 4 / 8 s, max. drei Versuche bei 5xx/429; kein Retry bei 401/403.
  8. Smoke-Test mit Dummy-Build; danach Freigabe in Produktion.

Build-Zusammenfassung zurück an TeamCity (REST + Retry)

Nach dem Preflight senden Sie ein kurzes JSON oder einen formatierten Kommentar an einen passenden /app/rest/…-Endpunkt — je nach TeamCity-Version und Plugin. Felder wie preflightMs, lockfileDrift (true/false), status (ok/warn/fail) und ein summaryText mit den letzten Zeilen stderr helfen Entwicklern in der Build-Übersicht. Verwenden Sie für den Rückkanal einen anderen Token als für den eingehenden Webhook.

TC_AUTH=$(printf '%s:%s' "$TC_USER" "$TC_PASS" | base64) for delay in 2 4 8; do code=$(curl -sS -o /tmp/tc-res.txt -w '%{http_code}' -X POST "$TEAMCITY_REST_URL/..." \ -H "Authorization: Basic $TC_AUTH" -H 'Content-Type: application/json' \ --data "$BODY" --connect-timeout 5 --max-time 30) [[ "$code" =~ ^2 ]] && break [[ "$code" == "401" || "$code" == "403" ]] && exit 1 sleep "$delay" done

Scheitert der Callback nach allen Versuchen, schreiben Sie BODY und buildId in eine Fehlerqueue auf dem Mac — der eingehende Webhook wurde bereits mit 2xx/202 bestätigt, wenn Sie async arbeiten. So vermeiden Sie widersprüchliche Zustände zwischen TeamCity-Timeout und langem Resolver.

FAQ: typische Fehler & Log-Ort

TeamCity meldet „Connection timed out“ zum Mac?

Firewall vom TeamCity-Server zur öffentlichen URL, falsches SNI oder Proxy ohne CONNECT. Mit curl -v direkt auf dem TeamCity-Host testen; DNS und MTU prüfen.

401 beim eingehenden Webhook?

Bearer falsch oder doppelt URL-kodiert; Reverse-Proxy entfernt Authorization. Konstantzeitig vergleichen und nie detaillierte Token-Fehler an TeamCity zurückgeben.

401/403 beim REST-Callback Mac → TeamCity?

PAT abgelaufen, falsches httpAuth-Schema oder fehlende Projektberechtigung — Credentials fixen, keine Endlos-Retries.

Preflight ok, aber Lockfile-Scan inkonsistent?

Falscher Referenz-Branch oder veralteter fetch; gleiche Remote-URLs wie der TeamCity-VCS-Root verwenden.

Wo loggen?

Anwendungslogs unter ~/Library/Logs oder vom LaunchAgent mit StandardOutPath; dazu log show --predicate … für launchd. Jede Zeile mit buildId versehen.

Nächste Schritte und CTA

Fazit: Die reproduzierbare Kette lautet: stabiler Remote-Mac mit Node 22+ und LaunchAgent-Daemon, Loopback-Gateway + TLS, TeamCity-Webhook mit Bearer/HMAC, schnelles ACK, Preflight + Lockfile-Drift im isolierten Workdir und REST-Summary mit 2/4/8-s-Backoff. Für Teams, die TeamCity-Queues entlasten und grenzüberschreitende Pulls konsolidieren wollen, ist ein gemieteter Mac-Knoten oft günstiger als dauerhaft überlastete Shared-Agenten. Ohne Login: Startseite, Hilfe, Kaufen, Preise und die OpenClaw-Praxis-Serie im Technik-Blog.

TeamCity · Webhook · OpenClaw · Remote-Mac

CI-Vorknoten mieten — TeamCity entlasten

Apple-Silicon, stabiler Egress, SSH-fertig: Preflight und OpenClaw-Gateway ohne Heimrechner-Risiko. Hilfe, Kaufen und Blog sind öffentlich.

Startseite Kaufen Preise Hilfe Blog / OpenClaw-Serie
Apple Silicon
stabiler Egress
Bearer & TLS