Netlify

L'intégration Netlify surveille les prévisualisations de déploiement et les déploiements de production via webhook. Quand un déploiement atteint l'état ready, Autonomy exécute le cas de test ou le plan de test configuré sur le permalien immuable par déploiement et, si un dépôt GitHub est lié, rapporte le résultat sous forme d'un check run GitHub sur le commit.

Ce qu'elle fait

• Reçoit un webhook à chaque changement d'état de déploiement (deploy_created, deploy_building, deploy_succeeded, deploy_failed, deploy_request_pending).
• Filtre par contexte de déploiement (deploy-preview, production ou branch-deploy) et par nom de branche.
• Exécute le cas de test ou le plan de test configuré sur l'URL du permalien immuable par déploiement.
• Rapporte le résultat sous forme d'un check run GitHub sur le commit lorsqu'un dépôt GitHub est lié.
• Netlify ne dispose d'aucune surface de check native — le rapport de statut repose entièrement sur le dépôt GitHub lié.
• Pour les déploiements issus de PR forquées retenus par Netlify pour approbation du propriétaire de l'équipe (deploy_request_pending), l'événement apparaît avec l'état « pending » dans le tableau de bord jusqu'à ce que le déploiement soit approuvé.

Pourquoi le permalien

Autonomy cible le permalien immuable par déploiement (https://<deploy_id>--site.netlify.app) plutôt que l'URL modifiable liée à la branche. Cela garantit que les résultats QA sont attribués à un commit exact — un push plus récent sur la même PR ne peut pas modifier ce que le runner voit en cours de test. L'URL de déploiement liée à la branche (deploy_ssl_url) n'est utilisée qu'en tant que solution de repli si le permalien est absent.

Configuration

1. Ouvrez Paramètres → Intégrations dans le tableau de bord Autonomy.
2. Cliquez sur Connecter sur la carte Netlify. Vous êtes redirigé vers Netlify pour autoriser l'application OAuth.
3. De retour dans Autonomy, cliquez sur Lier un site. Autonomy liste les sites Netlify visibles pour votre compte connecté — choisissez celui que vous voulez tester.
4. Choisissez un Cas de test ou un Plan de test comme cible d'exécution par défaut.
5. Choisissez l'Environnement dont la configuration doit s'appliquer.
6. Sous Contextes de déclenchement, sélectionnez quels types de déploiement démarrent une exécution — typiquement preview. Ajoutez des Filtres de branche pour limiter les exécutions à des branches spécifiques.
7. Pour rapporter les résultats sous forme de check GitHub, activez Rapporter les checks et sélectionnez le Dépôt lié. L'application GitHub Autonomy doit être installée sur ce dépôt.
8. Ouvrez une pull request et confirmez qu'une exécution démarre quand la prévisualisation de déploiement Netlify est prête.

Comment une exécution est déclenchée

Quand Netlify envoie un webhook deploy_succeeded :

1. Autonomy cherche le site lié par l'ID du site Netlify.
2. Le contexte de déploiement Netlify (deploy-preview, production, branch-deploy) est normalisé selon le vocabulaire d'Autonomy : preview, production ou branch.
3. Le contexte est vérifié par rapport aux contextes de déclenchement du site et la branche par rapport aux filtres de branche.
4. Si une cible de test par défaut est configurée, Autonomy crée une exécution ciblant l'URL du permalien immuable par déploiement.

Déploiements sur PR forquées

Lorsqu'un déploiement provient d'une pull request forquée, Netlify le retient pour approbation par le propriétaire de l'équipe et envoie un webhook deploy_request_pending. Autonomy enregistre l'événement avec l'état « pending » — il apparaît dans le tableau de bord en attente d'approbation. Une fois le déploiement approuvé et réussi, un webhook deploy_succeeded déclenche l'exécution comme d'habitude.

Sites protégés par mot de passe

Si le site Netlify bénéficie d'une protection par mot de passe (sur l'ensemble du site ou par déploiement), le runner ne peut pas atteindre la prévisualisation du déploiement. Pour configurer le contournement :

1. Dans Autonomy, ouvrez les paramètres du site lié.
2. Collez le mot de passe du site dans Secret d'accès à la prévisualisation.

Autonomy injecte le mot de passe selon les exigences du mécanisme de protection de Netlify. Le secret ne quitte jamais le backend.

Rapport de statut

Netlify n'expose aucune surface native de check ou de statut pour les intégrations tierces. Autonomy ne peut pas publier de résultats directement dans le tableau de bord Netlify.

Pour rapporter des résultats, liez un dépôt GitHub au site Netlify dans Autonomy. Quand c'est activé, Autonomy publie un check run GitHub sur le commit — le même mécanisme utilisé par l'application GitHub. Le check apparaît sur la pull request et peut devenir un check de statut requis sous la protection de branche.

Important : Si Rapporter les checks est activé mais qu'aucun dépôt GitHub n'est lié, les résultats n'apparaîtront que dans le tableau de bord Autonomy — pas sur la pull request ni nulle part dans Netlify. Le tableau de bord affiche un avertissement lorsque c'est le cas.

Monorepo et sites multiples

Un seul dépôt GitHub peut déployer plusieurs sites Netlify. Liez chaque site indépendamment dans Autonomy — chacun obtient sa propre cible de test, son environnement, ses contextes de déclenchement et ses filtres de branche. Tous les sites liés peuvent partager le même dépôt GitHub lié pour le rapport de statut.

Quand Netlify envoie un webhook, Autonomy l'associe au bon site lié grâce à l'ID du site Netlify.

Variables d'environnement (auto-hébergé)

Dépannage

Aucune exécution ne démarre quand une prévisualisation de déploiement est prête

Vérifiez les points suivants :

• Le compte Netlify est connecté et affiche Actif dans Autonomy.
• Le site Netlify est lié. Autonomy ne surveille que les sites liés.
• Le site est activé. Un site désactivé enregistre l'événement mais omet l'exécution (project disabled).
• Le contexte de déploiement est présent dans les contextes de déclenchement du site. deploy-preview de Netlify correspond à preview, production à production, et branch-deploy à branch. Une non-correspondance omet l'événement avec context <x> not enabled.
• La branche correspond aux filtres de branche du site. Une non-correspondance omet l'événement avec branch <x> filtered.
• Un cas de test ou plan de test par défaut est sélectionné. Sans cela, l'événement est omis avec no default test target.
• Le déploiement a atteint l'état ready. Un déploiement en état building ou error ne déclenche pas d'exécution (deployment not ready).
• L'URL de prévisualisation du déploiement est présente. Si le webhook n'incluait pas d'URL de prévisualisation, l'événement est omis avec no preview URL.

Un déploiement est bloqué en statut « pending »

Si un déploiement apparaît comme « pending » dans Autonomy et ne déclenche jamais d'exécution, il s'agit probablement d'un déploiement sur PR forquée retenu par Netlify pour approbation du propriétaire de l'équipe (deploy_request_pending). Approuvez le déploiement dans Netlify — un webhook deploy_succeeded suivra et déclenchera l'exécution.

L'exécution ne peut pas atteindre la prévisualisation de déploiement

L'URL de prévisualisation du déploiement peut être bloquée par une protection par mot de passe au niveau du site. Si l'exécution échoue sur une page de mot de passe, ajoutez le mot de passe du site comme Secret d'accès à la prévisualisation.

Aucun check n'apparaît sur la pull request

Netlify n'a pas de surface native de checks. Le rapport de statut nécessite :

1. Rapporter les checks activé sur le site lié.
2. Un Dépôt lié sélectionné.
3. L'application GitHub Autonomy installée sur ce dépôt.

Si l'un de ces éléments manque, le statut de rapport de l'événement est unsupported et aucun check n'est publié. Si les checks sont activés mais qu'aucun dépôt n'est lié, les résultats apparaissent uniquement dans le tableau de bord Autonomy.

Exécutions en double pour le même déploiement

Autonomy déduplique les événements grâce à une clé incluant l'ID de déploiement Netlify et son état. Un webhook renvoyé ne produit pas de seconde exécution.