npm install -g openclaw), openclaw onboard, le tableau de bord ou l’API gateway, la création du Webhook, une validation curl reproductible, puis le dépannage lorsque rien n’apparaît. Pour le cadre général : déploiement passerelle ; pour jetons et proxy : sécurité passerelle. Accueil, tarifs et centre d’aide MacPull restent accessibles sans connexion.
Environnement, versions Node et principe de moindre privilège
Installez OpenClaw selon la doc de votre branche : script officiel (souvent une ligne curl pipée vers bash) ou npm install -g openclaw si l’entreprise impose npm. Alignez Node.js avec les prérequis de la release : en pratique Node 22 LTS minimum et Node 24 lorsque le projet le recommande explicitement. Contrôlez node -v dans votre session SSH et dans le même contexte que le service (launchd) : un PATH différent suffit à des échecs nocturnes silencieux.
openclaw onboard initialise répertoires, exemples de configuration et parfois un jeton pour le dashboard local ou l’API gateway. Poursuivez avec openclaw doctor jusqu’à l’absence d’erreurs bloquantes ; ouvrez ensuite l’URL indiquée pour confirmer que l’état affiché correspond au fichier de config réellement chargé par le processus.
- Secrets : jamais dans l’historique shell ni dans Git ; fichier dédié
chmod 600ou coffre central. - Passerelle : écoute
127.0.0.1lorsque possible ; TLS et filtrage sur le reverse proxy si besoin d’URL publiques. - CI : éviter une notification par étape ; file, délai ou dédup par
build_id.
| Emplacement | Intérêt | Risque résiduel |
|---|---|---|
Env fichier 600 | launchd, hors git. | Backup chiffré. |
| Vault / cloud | Rotation, audit. | Latence boot. |
| Webhook dans JSON versionné | Risque commit. | Fuite dépôt. |
Création du Webhook Discord et liaison côté passerelle
Dans Discord : paramètres du salon, Intégrations, Webhooks, création d’un webhook nommé (ex. « CI OpenClaw »), copie de l’URL complète. Toute personne possédant cette URL peut poster : limitez les captures d’écran partagées et prévoyez une rotation après départ d’un opérateur ayant eu accès.
Côté OpenClaw, renseignez la clé dans le bloc notifications ou channels documenté pour votre version, en lisant DISCORD_WEBHOOK_URL depuis l’environnement du service plutôt qu’en dur dans un fichier versionné. Après modification, rechargez launchd ou redémarrez le processus passerelle et vérifiez les journaux pour une erreur de chargement d’env.
Validation minimale depuis le Mac (sans passer par la CI) :
204 = succès courant ; documentez-le. Proxy : même HTTPS_PROXY / NO_PROXY en plist que dans Telegram / Slack / webhooks.
Modèle de payload pour résumé de build et correspondance des champs
Le corps accepté par Discord combine en général un texte content et, pour plus de structure, un tableau embeds avec titre, couleur entière et champs nom-valeur. Pour la CI, figez un schéma minimal que vos scripts ou la passerelle réutilisent à chaque pipeline afin d’éviter les surprises de rendu dans le salon.
| Source CI | Cible Discord | Remarque |
|---|---|---|
| ID run CI | Titre / content | Support. |
git rev-parse --short | Champ commit | Hash court si politique stricte. |
| Statut | Couleur / emoji | 3066993 vert, 15158332 rouge. |
| Logs URL | description | Sans jetons. |
Signature côté Discord, limites de débit et paramètres de retry
À la différence d’une application Discord OAuth complète, l’Incoming Webhook ne signe pas vos requêtes sortantes : la protection repose sur la confidentialité de l’URL, la segmentation réseau et l’absence de fuite dans les logs applicatifs ou les artefacts CI. Traitez toute ligne de log contenant l’URL comme sensible.
Discord impose un débit maximal par webhook ; une matrice parallèle peut provoquer des 429. Configurez un client HTTP avec timeouts de connexion et de lecture séparés, un backoff exponentiel 2s / 4s / 8s borné à trois essais pour les erreurs transitoires, une petite composante aléatoire (jitter) pour éviter l’effet troupeau, et une file si plusieurs jobs se terminent ensemble. Ne relancez pas mécaniquement sur 403 : corrigez plutôt l’URL, le salon ou le pare-feu sortant.
FAQ — 403, 429, timeouts et absence de message
403 : URL révoquée, salon archivé ou TLS rompu — régénérer l’URL, curl -v Mac vs CI avec même magasin CA si PKI interne.
429 : un message fin de pipeline ou un embed agrégé plutôt que plusieurs posts.
Timeouts : runner ≠ SSH — augmenter délais client, vérifier proxy et blocage sortant vers discord.com.
204 sans message : bon salon, filtres utilisateur, content non vide après template.
Synthèse : Node homogène, onboard/doctor, webhook hors git, test curl, CI respectant le débit Discord. Suite passerelle : multi-endpoints & résumé CI. Pour Mac cloud dédié gateway/runners : achat, tarifs, aide, blog.
Automatisez les synthèses de build sur un Mac distant stable
Parcours sans compte : accueil, aide, achat, articles OpenClaw & passerelle.