2026 OpenClaw MeshMac en pratique : Webhook Google Chat pour diffuser l’état de build multi-nœuds

Adoptez la topologie passerelle d’abord décrite dans le guide de déploiement multi-nœuds MeshMac : un hôte stable (petite VM Linux, bastion ou Mac désigné) exécute les services OpenClaw, détient les webhooks sortants et lit les secrets dans un répertoire scellé. Les builders enregistrent des événements ; ils ne doivent pas chacun conserver une copie de l’URL Chat.

Après installation, fixez OPENCLAW_CONFIG_ROOT, terminez l’onboarding et lancez les contrôles de santé pour que le démon démarre avec le même environnement que votre pipeline. Placez la cible webhook dans un fichier du type /etc/openclaw/secrets.d/google-chat/build-status.url en mode 0440, propriétaire root, groupe openclaw-notify. Centralisez la livraison interne depuis plusieurs Mac via le modèle de déploiement unifié et file de tâches synchronisée afin qu’aucun runner ne duplique la logique d’émission.

Point de contrôle A — permissions fichier.

sudo install -d -m 0750 -o root -g openclaw-notify /etc/openclaw/secrets.d/google-chat
sudo sh -c 'umask 077; cat > /etc/openclaw/secrets.d/google-chat/build-status.url' <<'EOF'
https://chat.googleapis.com/v1/spaces/SPACE/messages?key=KEY&token=TOKEN
EOF
sudo chown root:openclaw-notify /etc/openclaw/secrets.d/google-chat/build-status.url
sudo chmod 0440 /etc/openclaw/secrets.d/google-chat/build-status.url

Tutoriel multi-plateformes : pour Teams, autorisez les hôtes Microsoft et des cartes MessageCard ; pour Matrix, jetons de salle ou appservice. La table de champs normalisés et la file unique restent identiques — seuls le moteur de rendu et l’endpoint changent.

Dans l’espace Google Chat cible, ajoutez l’intégration Webhook entrant (nommez-la d’après le dépôt ou le pool), choisissez l’espace et copiez l’URL générée une fois. Les paramètres de requête key et token jouent le rôle d’un secret porteur : en cas de fuite, révoquez et recréez le webhook — pas de rotation partielle.

• Espaces séparés par environnement pour qu’un workflow de préproduction ne poste pas un faux « vert » dans l’espace exécutif.
• Sortie réseau : depuis le shell de la passerelle, vérifiez le TLS vers chat.googleapis.com avec les mêmes variables HTTPS_PROXY que le démon.
• Politique admin : si Workspace bloque les webhooks personnalisés, passez par une application Chat approuvée ou un point de terminaison HTTP (Apps Script) tout en conservant un seul émetteur passerelle.

Point de contrôle B — joignabilité.

export HTTPS_PROXY="${HTTPS_PROXY:-}"
curl -sS -o /dev/null -w "%{http_code}\n" -I "https://chat.googleapis.com/"

Une réponse contrôlée par Google (souvent 404 sur GET nu) est acceptable ; en revanche, des échecs de poignée TLS ou un 403 proxy indiquent un problème de politique à résoudre avant de déboguer le JSON applicatif.

Le corps minimal fiable pour du texte généré par application est du JSON UTF-8 avec un champ text. Les cartes et widgets peuvent attendre que la livraison texte soit prouvée.

export CHAT_URL="$(sudo cat /etc/openclaw/secrets.d/google-chat/build-status.url)"
curl -sS -X POST "$CHAT_URL" \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -d '{"text":"Sonde passerelle MeshMac : OK depuis '"$(hostname -s)"'"}'

Point de contrôle C — message visible. La ligne de sonde doit apparaître dans l’espace en quelques secondes. Si l’API renvoie un objet d’erreur JSON, corrigez le corps avant d’activer l’automatisation complète.

En production, formatez une ligne avec emoji ou libellés pour state, ajoutez mesh_node_id et un hash de commit court ; respectez les limites de longueur Chat et renvoyez vers run_url plutôt que de coller des journaux. Pour Teams ou Matrix, adaptez uniquement le schéma JSON et l’hôte — la passerelle et la file restent les mêmes.

Imaginez trois builders MeshMac qui terminent dans la même minute. Chaque runner publie un enregistrement normalisé vers Redis, NATS ou le tissu de tâches OpenClaw. Le consommateur passerelle mappe les charges fournisseur vers une forme interne commune avant de produire le champ text :

Exemple de ligne rendue (un seul POST) :

✅ ios-release · main · abc1234 · <https://github.com/org/repo/actions/runs/18451203> · nœud mm-pool-2

Si deux nœuds rapportent le même provider_run_id et state, la passerelle doit dédupliquer sur une fenêtre (souvent 24 à 72 h) pour éviter le spam. Alignez la mécanique avec le guide file de tâches et étapes de retry pour la file interne, distincte du « relancer le build ».

L’URL du webhook est-elle un jeton OAuth ?

Non : c’est un secret d’endpoint HTTPS non scopes. Protégez-la comme une clé API : ACL disque, pas de Git, journaux réduits (hôte plus quatre derniers caractères du paramètre token).

Quels codes HTTP doivent déclencher un retry ?

Retry 429 et 5xx avec backoff exponentiel, jitter et plafond (par exemple cinq tentatives sur deux minutes). Ne retry pas 400 ou 401 : corrigez le JSON ou régénérez le webhook. Un 404 répété signifie souvent « webhook supprimé ».

Comment éviter les messages Chat en double ?

Stockez les livraisons réussies sous provider_run_id + state dans SQLite, Redis ou un cache local passerelle. Ignorez un second POST si la clé existe dans la fenêtre de déduplication.

Les builders peuvent-ils appeler Chat directement « le temps de tester » ?

Cela multiplie les secrets et les règles d’egress. Consolidez sur un processus passerelle unique pour que rotation, audit et exercices de bascule restent prévisibles.