OpenClaw · API Deployments GitHub · Lighthouse · Mac distant · Webhooks · 2026

2026 OpenClaw, pratique front sur Mac distant :
GitHub Deployments, régression Lighthouse, seuils et digest lisible en pull request

22 avril 2026 Automatisation web / portes release 10 min de lecture

Public : équipes qui font tourner OpenClaw sur un Mac loué et veulent un fil GitHub neutre vis-à-vis du fournisseur PaaS montrant si la preview a régressé côté performance réelle, sans donner à l’automation un jeton « carte blanche ». Ce HowTo enchaîne webhooks, API Deployments, Lighthouse, seuils numériques et un commentaire PR court. Slug fichier unique (pas de sous-dossiers) : 2026-openclaw-remote-mac-github-deployments-lighthouse.html. Lectures voisines : alertes Lighthouse planifiées, Lighthouse pré-déploiement et liens, fumée Deployment Hook Vercel, métriques de build en résumé PR.

Les URL de preview changent vite : caches froids, cookies d’auth, HTTP/3 et polices diffèrent entre CI et navigateur bureau. Un Mac distant loué rapproche composite GPU, rendu et canal Safari/Chromium de la réalité produit, hors console PaaS. Les checks restent bruyants pour des profils non techniques ; l’onglet Déploiements et une environment_url lisibles comptent. OpenClaw orchestre : webhook signé → déploiement → Lighthouse sur le Mac → seuils → deployment_status et digest identique en PR.

« Terminé » : preview/lighthouse passe de pending à success ou failure avec un résumé court ; commentaire PR optionnel qui copie le même texte. Déduplication sur la passerelle, pas dans chaque script.

01 Modèle de liaison : webhook, déploiement et statut

Webhook = intention ; objet déploiement = corrélation GitHub ; deployment_status = verdict lisible pour la preview. La plateforme prouve le bord réseau ; le Mac prouve l’enveloppe performance utilisateur face aux seuils versionnés.

Signal Idéal pour Piège fréquent
Webhook dépôt Déclencher le job Mac avec des charges repository_dispatch contenant preview_url et pr_number. Rejeux sans idempotence → déploiements dupliqués et chronologies incohérentes.
Déploiement + statuts Une ligne par couple commit / environnement, sémantique pending → succès ou échec claire. Réutiliser le nom d’environnement de production pour des previews → audits de rollback impossibles.
Commentaire PR Narratif recherchable pour ceux qui n’ouvrent jamais l’onglet Déploiements. Coller secrets, cookies ou URL signées à longue TTL dans le corps du commentaire.

Alignez ce flux sur les champs d’observabilité décrits dans résumé E2E tokens et auth sur passerelle afin que les compteurs passerelle et les durées Lighthouse partagent le même n-uplet OPENCLAW_RUN_ID dans les journaux NDJSON.

02 Étapes HowTo reproductibles

  1. Geler les identifiants. Exportez GIT_SHA, PREVIEW_URL, PR_NUMBER, REPO au format propriétaire/nom, OPENCLAW_RUN_ID, et optionnellement BASELINE_REF pour lire une médiane dans les artefacts verts récents.
  2. Créer un déploiement. POST /repos/{owner}/{repo}/deployments avec ref sur le SHA du commit, un environment du type preview/lighthouse, et des payload ou métadonnées qui répètent OPENCLAW_RUN_ID. Conservez deployment.id.
  3. Émettre pending. POST .../deployments/{id}/statuses avec state=pending et une description du genre mac-distant: chauffe preview pour signaler que la sonde n’a pas encore fini.
  4. Chauffer la preview. Depuis le Mac, deux GET idempotents (document HTML + bundle JS principal) avec le même user-agent que Lighthouse ; courte pause si la plateforme renvoie 429.
  5. Exécuter Lighthouse. CLI ou LHCI avec Chromium épinglé ; écrire lhr.json sous .openclaw/reports/${OPENCLAW_RUN_ID}.lhr.json pour rattacher chaque rapport à une exécution précise.
  6. Seuils. Extraire score performance, LCP, CLS, TBT ; comparer aux baselines dans perf/baselines.json ou à une médiane glissante — même esprit que les portes d’alerte Lighthouse et le contrôle pré-déploiement liens / a11y.
  7. Mettre à jour deployment_status. success ou failure avec description compacte : uniquement des deltas chiffrés, jamais de jetons. Renseignez environment_url sur PREVIEW_URL et, si besoin, log_url vers un objet stocké pré-signé à courte durée de vie.
  8. Miroir PR. Publiez un commentaire sur la pull request avec le même texte que la description de statut pour que la chronologie de revue reste honnête.
  9. Idempotence. Exigez Idempotency-Key: ${GIT_SHA}:${OPENCLAW_RUN_ID}:lighthouse sur la passerelle avant tout appel GitHub afin que deux hooks plateforme ne forkent pas deux déploiements parallèles.
  10. Journal NDJSON OpenClaw. Appendez une ligne phase=lighthouse_github avec deployment_id, verdict et duration_ms pour le triage ultérieur, en cohérence avec les résumés PR autour du service worker.
# En-tête minimal que la passerelle doit imposer avant d’appeler GitHub
curl -H "Authorization: Bearer ${GITHUB_TOKEN}" \
     -H "Accept: application/vnd.github+json" \
     -H "X-GitHub-Api-Version: 2022-11-28" \
     -H "Idempotency-Key: ${GIT_SHA}:${OPENCLAW_RUN_ID}:lighthouse" \
     https://api.github.com/repos/${REPO}/deployments
À retenir

Gardez les descriptions de statut sous environ quatre kilo-octets : GitHub tronque agressivement et les clients mobiles ellipsent tôt.

03 Jetons à blast radius minimal

Les PAT classiques avec portée repo complète sont tentants mais dangereux pour un Mac partagé en labo longue durée. Préférez un PAT finement granulaire limité à un dépôt, ou un jeton d’installation GitHub App émis par job.

Permission Pourquoi le Mac en a besoin Ce qu’il faut éviter
Contents : lecture Cloner ou récupérer les fichiers de seuils sur le même commit. Écriture dépôt sauf rôle séparé si le runner doit pousser des baselines.
Deployments : lecture et écriture Créer les déploiements et poster les transitions deployment_status. Jetons admin d’organisation partagés entre dizaines de dépôts.
Pull requests : écriture Publier le digest lisible en commentaire. Réutiliser un bot capable de merger ou de modifier les règles de protection.
Métadonnées : lecture Obligatoire sur les PAT fins ; gardez l’audit ailleurs. Exporter le PAT dans des bundles front ou des rapports HTML Lighthouse.

Stockez les secrets dans la passerelle OpenClaw ou le trousseau macOS ; faites tourner la rotation sur une cadence plus courte que la durée de vie de vos URL de preview les plus longues. Pour la partie « preuve réseau » avant Lighthouse, croisez avec la fumée hook Vercel et l’audit d’en-têtes lorsque votre preview est derrière la même infrastructure.

04 Dépannage

  • 404 sur /deployments. Vérifiez que le PAT ou l’app voit bien le dépôt : les PAT fins échouent silencieusement si le dépôt n’est pas dans la liste autorisée.
  • Doublons de déploiements par commit. Dédupliquez côté serveur sur (environment, ref) ou réutilisez l’identifiant du dernier déploiement renvoyé par l’API liste avant d’en créer un nouveau.
  • Lighthouse vert en local, rouge sur preview. Souvent cookies d’auth ou en-têtes géo : injectez uniquement des identifiants de test via variables d’environnement, jamais dans le corps du commentaire PR.
  • LCP erratique. Épinglez Chromium, réduisez la charge CPU du Mac pendant la sonde, comparez à la médiane des trois derniers runs verts plutôt qu’à un chiffre d’or unique figé dans un vieux ticket.
  • Pluie de commentaires. Upsertez un seul commentaire marqué par un commentaire HTML caché du type <!-- openclaw-lh:${GIT_SHA} --> en réutilisant l’API des issues lorsque votre bot est propriétaire du message.

Après Lighthouse, enchaînez si besoin la fumée web pré-déploiement et le triage des journaux E2E pour classer les échecs « infra » versus « produit » sans mélanger les responsabilités dans le même statut.

05 FAQ

Pourquoi ne pas seulement des artefacts GitHub Actions ?

Les artefacts aident les ingénieurs mais restent invisibles pour beaucoup de parties prenantes. Les lignes de déploiement voyagent avec l’URL d’environnement et se lisent sur téléphone ; gardez les artefacts pour le lhr.json brut, et deployment_status pour le verdict court.

Safari peut-il piloter le même statut de déploiement ?

Oui : remplacez Lighthouse par une sonde WebKit, mais conservez le même deployment.id et la même clé d’idempotence pour ne pas forker les tableaux de bord par navigateur.

Faut-il admin:repo_hook sur le jeton du Mac ?

Non pour poster les statuts si le webhook est déjà configuré au niveau dépôt ou org. Le job Mac a besoin des portées déploiement et pull request, plus une vérification de signature webhook à la passerelle — pas d’administration globale des hooks depuis le runner.

OpenClaw · Mac distant · sans compte obligatoire

Industrialisez les portes perf sans sur-dimensionner les jetons

Parcourez l’accueil, les tarifs, l’aide et la page achat ou location sans étape de connexion. Poursuivez avec les alertes Lighthouse, les métriques de build en PR, et l’index du blog pour d’autres playbooks OpenClaw.

API Deployments Lighthouse Moindre privilège
Louer un Mac Tarifs Blog
Mac distant — OpenClaw & Lighthouse