2026 OpenClaw MeshMac en pratique : filtre de chemins monorepo, build incrémental multi-nœuds et résumé Slack — runbook minimal

Tout commence par un ancre de diff fiable. Sous GitHub Actions, l’action dorny/paths-filter ou un script qui exécute git diff --name-only "$BASE_SHA"...HEAD suffit pour une première version exploitable. Chaque fichier modifié doit être rattaché à une racine de paquet : par exemple apps/ios/** → apps/ios, packages/core/** → packages/core. Stockez ce mapping dans un YAML versionné : les relecteurs voient les faux négatifs avant la prod.

Produisez un seul artefact pour la suite du pipeline : un tableau JSON du type ["apps/ios","packages/core"] ou une liste lignes. Si le filtre ne touche rien d’obligatoire, basculez sur une cible fumée peu coûteuse plutôt que sur une matrice complète. Avec Turborepo, Nx ou Bazel, remplacez les globs manuels par des commandes affected — le contrat reste identique : chaque nœud MeshMac lit le même plan normalisé et sait quoi compiler.

Sur main et les branches release, si ci/** ou .github/** change, élargissez une fois le plan puis revenez à l’incrémental. Pour worktrees et lockfiles, voir la matrice Git worktree et verrous.

Point de contrôle A. Archivez le JSON du plan avec les journaux du job pour rejouer la même entrée en debug.

Le build incrémental ne supprime pas les conflits sur identité de signature, caches simulateur ou bac CocoaPods. Deux jobs qui empruntent des chemins différents peuvent encore s’écraser. Choisissez un modèle et documentez-le dans le runbook MeshMac :

• File centrale — Les workers consomment Redis, RabbitMQ ou le tissu décrit dans déploiement unifié et file de tâches synchronisée ; plafonnez les consommateurs à un par « voie » lorsque Xcode entre en jeu.
• Coopération flock — Un volume NFS ou APFS partagé héberge /build-locks/ios.signing.lock ; utilisez flock avec timeout. Voir la FAQ file de build et flock pour les verrous périmés.

Alignez le verrou sur le rate limit passerelle et le guide multi-nœuds MeshMac (topologie passerelle d’abord).

Point de contrôle B. Deux jobs « signing » en parallèle ne se résolvent pas par le path filter : corrigez la concurrence d’abord.

Les journaux CI bruts noient Slack ; personne ne lit douze mille lignes sur mobile. Après la sortie du step build, enfilez une tâche côté passerelle qui ingère des entrées structurées : code de sortie, liste des paquets du plan, mesh_node_id, durée murale, premier test ou erreur compilateur. La sortie doit tenir en moins de quatre cents mots, énumérer les chemins effectivement buildés et pointer vers l’URL du run fournisseur.

Passez le JSON du path filter dans le contexte de la tâche : la synthèse commence par « Paquets buildés : … » au lieu de deviner depuis le bruit. Si vous exportez des bundles xcresult, orientez OpenClaw vers la tranche plist/JSON qui liste les tests en échec plutôt que vers la transcription complète xcodebuild. Les runs verts peuvent utiliser un gabarit statique type Handlebars : latence prévisible quand cinq nœuds terminent dans la même minute.

Pas de secrets dans le résumé : credential_id ou nom de job seulement. Champs normalisés : webhook build partagée ; playbooks : hub OpenClaw.

Point de contrôle C. Vérifiez les résumés d’échec : pas d’URL signées ni de clés.

Le webhook entrant historique Slack est une URL HTTPS unique vers un canal : pratique et risquée — quiconque possède l’URL peut spammer le canal. Traitez-la comme un secret porteur : fichier en 0440, propriétaire root ou utilisateur passerelle, groupe du type openclaw-notify, jamais dans Git. Seul l’hôte passerelle lit l’URL et exécute le POST ; les runners poussent des événements vers la file passerelle.

Sortie réseau : liste blanche hooks.slack.com (et le SNI du proxy d’entreprise si besoin). Validez avec curl depuis la passerelle avant d’activer l’automatisation :

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

Pour l’arborescence des secrets et le moindre privilège par nœud, calquez-vous sur secrets et permissions minimales sur les nœuds MeshMac. Lorsque vous dépasserez les webhooks entrants, migrez vers une app Slack à jetons limités — en conservant la discipline un seul émetteur.

Point de contrôle D — visibilité immédiate. La ligne de sonde doit apparaître dans le canal en quelques secondes ; un 400 indique un corps JSON ou un webhook révoqué à corriger avant tout retry automatique.

Slack renvoie parfois 429 ou des 5xx transitoires. Réessayez avec backoff exponentiel, jitter complet et un plafond — par exemple cinq tentatives sur deux minutes. Une forme utile : aléa(0, min(plafond_ms, base * 2**tentative)) pour éviter que des runners CI synchronisés martèlent la même seconde. Respectez l’en-tête Retry-After lorsqu’il est présent.

Ne réessayez pas 400 ou 404 : corrigez le JSON ou régénérez le webhook. Dédupliquez sur provider_run_id + conclusion au moins soixante-douze heures pour que les relances CI bruitées ne postent pas en double. La sémantique de retry au niveau file interne reste celle du guide file de tâches et étapes de retry, distincte du « relancer le build ».

Point de contrôle E. Retries Slack saturants → baisser la concurrence (rate limit passerelle) avant d’ajouter des workers.

Les rotations doivent être répétables : même ordre d’opérations en préproduction et en prod. Le tableau suivant résume les surfaces courantes ; détaillez les étapes dans votre runbook d’équipe.

Derrière un LB : failover multi-nœuds ; rotation multi-canaux : canaux d’alerte et jetons.

Puis-je supprimer le verrou si les builds sont déjà incrémentaux ?

L’incrémental réduit le temps CPU, pas la contention sur signature, simulateurs ou caches globaux. Gardez un verrou étroit autour de ces phases même lorsque le filtre de chemins est exact.

OpenClaw doit-il appeler un LLM à chaque build vert ?

Non. Utilisez un gabarit pour les succès (emoji, durée, paquets) et réservez le modèle aux échecs ou aux erreurs marquées ambiguës par le parseur.

Le webhook entrant Slack est-il déprécié ?

Slack oriente les nouveaux espaces vers les apps, mais les webhooks entrants restent très utilisés en CI interne. Prévoyez une migration sans bloquer la boucle minimale décrite ici.