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

Dans Mattermost, créez une intégration Incoming Webhook pointant vers le canal souhaité (selon votre version : menu du canal Intégrations ou politique définie par l’administrateur système). L’URL générée — du type https://mattermost.exemple.com/hooks/… — est un jeton porteur : quiconque peut y poster peut spammer le canal. Stockez-la par exemple dans /etc/openclaw/secrets.d/mattermost/build-status.url avec le mode 0440, sur le modèle de secrets et moindre privilège sur les nœuds MeshMac.

Corps de requête. Mattermost attend en général du JSON avec au minimum "text" (Markdown pris en charge) ou des attachments pour les tableaux, couleurs de barre latérale et champs structurés. Définissez Content-Type: application/json. Pour un résumé de build lisible sur mobile, un message court en text plus un lien suffit souvent ; pour les équipes qui veulent une ligne par étape (lint, tests, signature), préparez plutôt un tableau d’attachments avec color (succès vert, échec rouge) et des fields nom/valeur. Si le canal impose un préfixe ou un compte de bot, respectez les options exposées à la création du webhook (nom d’utilisateur affiché, canal verrouillé ou surchargé par paramètre channel lorsque la politique du serveur l’autorise).

Ordre opératoire minimal. Déployer la passerelle (doctor), créer le webhook Mattermost et l’URL secrète, tester un POST depuis la passerelle, brancher la file des workers, puis activer retries et déduplication avant la production — ainsi vous évitez d’attribuer à tort une panne « réseau » à un JSON ou un secret encore incorrect.

• Ne jamais journaliser l’URL complète. En débogage, journalisez l’hôte Mattermost et les quatre derniers caractères du segment secret.
• Santé réseau. Depuis la passerelle, testez curl -I vers l’hôte du serveur avec les mêmes HTTP(S)_PROXY que le démon OpenClaw.
• Limiter la concurrence. Si plusieurs goroutines postent en parallèle, alignez-vous sur rate limit et concurrence à la passerelle pour éviter les rafales 429 côté Mattermost.

Chaque fournisseur CI émet un JSON différent. Normalisez sur la passerelle avant de formater le message Mattermost : une ligne de titre lisible, un lien vers les journaux, et l’identifiant du nœud du pool évitent les allers-retours SSH.

1. Émettre depuis chaque worker un événement compact (fichier append-only, Redis, ou file décrite dans file de tâches et retry) contenant au minimum workflow, state, branch, commit, run_url, mesh_node_id, provider_run_id.
2. Fusionner ou séquencer sur la passerelle : soit un message unique par transition d’état pour un provider_run_id, soit un fil de messages courts si votre équipe préfère l’historique brut — dans les deux cas, une seule entité logicielle appelle Mattermost.
3. Enrichir pour l’humain : emoji ou mot-clé pour succès, échec, annulation ; durée optionnelle si vous lisez la même métrique que la file de tâches OpenClaw.

Si plusieurs nœuds appelaient auparavant le webhook en direct, consolidez et retirez leurs exceptions réseau : la surface d’attaque diminue et les bascules décrites dans permissions cluster et bascule ne concernent plus qu’un petit ensemble d’adresses IP passerelle.

En production, gardez une cohérence de fuseau dans les horodatages affichés (UTC en entête du message, heure locale seulement si toute l’équipe partage la même région) et limitez la longueur des journaux collés dans Mattermost : un extrait de dix lignes plus le lien run_url vaut mieux qu’un copier-coller de milliers de caractères qui fait échouer les clients légers.

Le webhook Mattermost n’a pas de signature HMAC séparée comme certains fournisseurs SaaS : la confidentialité de l’URL fait office de secret. Traitez-la comme les autres récepteurs dans webhook OpenClaw : build partagé et notifications : pas dans le dépôt Git, pas dans les variables d’environnement visibles des jobs utilisateur, rotation documentée.

• Séparation des environnements. Canaux et webhooks distincts pour staging et production.
• Rotation. Révoquez le webhook dans Mattermost, créez-en un nouveau, remplacez le fichier secret, rechargez la passerelle — procédure alignée sur canaux d’alerte et rotation des jetons.
• Egress. Autorisez uniquement la passerelle à joindre le ou les hôtes Mattermost (et le proxy sortant si TLS inspection). Les runners CI n’ont pas besoin d’Internet général pour notifier.
• Retries. Sur 429 ou 5xx, backoff exponentiel avec jitter et plafond de tentatives ; ne pas boucler sur 400 ou 404 (URL révoquée ou JSON invalide).

Idempotence : dérivez une clé de provider_run_id plus state et ignorez un second envoi lorsque la même transition a déjà été acquittée avec succès pendant une fenêtre d’au moins 72 heures — même logique que pour Microsoft Teams dans notre guide Teams webhook multi-nœuds.

La CI est verte mais le canal reste vide

Vérifiez dans les journaux structurés de la passerelle qu’un POST a bien été exécuté et quel code HTTP a été retourné. Testez avec curl depuis la passerelle et un corps minimal {"text":"test meshmac"}. Confirmez que le webhook n’a pas été désactivé par l’administrateur système.

HTTP 200 mais rien n’apparaît dans le canal

Certains serveurs acceptent la requête mais ignorent le contenu si le canal cible a été verrouillé ou si le webhook était lié à un canal supprimé puis recréé avec le même nom. Vérifiez aussi qu’un filtre de contenu ou un plugin n’écarte pas les messages de bot.

Échecs intermittents depuis certains nœuds seulement

Ces machines appellent probablement encore Mattermost en direct avec un ancien secret ou contournent le proxy. Imposez le chemin passerelle unique et supprimez les règles d’egress par nœud.

Erreur TLS ou certificat

Importez l’AC interne dans le magasin de confiance du processus OpenClaw si Mattermost utilise une PKI d’entreprise ; les tests depuis un navigateur ne suffisent pas si le démon utilise un autre magasin.

HTTP 400 ou « unable to parse request body »

Contrôlez l’encodage UTF-8, les guillemets JSON et l’absence de caractères de contrôle dans text. Si vous sérialisez depuis un shell, méfiez-vous des expansions et des retours ligne non échappés.

Tout fonctionnait jusqu’à lundi matin

Croisez avec la rotation des certificats proxy le week-end, la révocation d’un webhook lors d’un audit, et les changements de pare-feu. Réutilisez les runbooks de rotation des jetons et canaux.

D’autres articles OpenClaw sont regroupés sur la page OpenClaw du blog.