Netlify

La integración de Netlify supervisa las previsualizaciones de despliegue y los despliegues de producción mediante webhook. Cuando un despliegue alcanza el estado ready, Autonomy ejecuta el caso de prueba o plan de pruebas configurado contra el enlace permanente (permalink) inmutable por despliegue y, si hay un repositorio de GitHub vinculado, informa el resultado como un check run de GitHub en el commit.

Qué hace

• Recibe un webhook en cada cambio de estado del despliegue (deploy_created, deploy_building, deploy_succeeded, deploy_failed, deploy_request_pending).
• Filtra por contexto de despliegue (deploy-preview, production o branch-deploy) y nombre de rama.
• Ejecuta el caso de prueba o plan de pruebas configurado contra la URL del enlace permanente (permalink) inmutable por despliegue.
• Informa el resultado como un check run de GitHub en el commit cuando hay un repositorio de GitHub vinculado.
• Netlify no tiene una superficie nativa de checks — el reporte de estado depende completamente del repositorio de GitHub vinculado.
• Para despliegues de PRs desde forks retenidos por Netlify para la aprobación del propietario del equipo (deploy_request_pending), el evento aparece con estado "pending" en el panel hasta que se apruebe el despliegue.

Por qué el enlace permanente (permalink)

Autonomy se dirige al enlace permanente (permalink) inmutable por despliegue (https://<deploy_id>--site.netlify.app) en lugar de la URL mutable del ámbito de rama. Esto garantiza que los resultados de QA se atribuyan a un commit exacto — un nuevo push a la misma PR no puede cambiar lo que ve el runner a mitad de la prueba. La URL de despliegue del ámbito de rama (deploy_ssl_url) se usa solo como alternativa si el enlace permanente no está presente.

Configuración

1. Abre Ajustes → Integraciones en el panel de Autonomy.
2. Haz clic en Conectar en la tarjeta de Netlify. Serás redirigido a Netlify para autorizar la aplicación OAuth.
3. De vuelta en Autonomy, haz clic en Vincular sitio. Autonomy lista los sitios de Netlify visibles para tu cuenta conectada — elige el que quieras probar.
4. Elige un Caso de prueba o Plan de pruebas como objetivo de ejecución predeterminado.
5. Elige el Entorno cuya configuración debe aplicarse.
6. En Contextos de activación, selecciona qué tipos de despliegue inician una ejecución — normalmente preview. Añade Filtros de rama para limitar las ejecuciones a ramas específicas.
7. Para reportar resultados como un check de GitHub, activa Reportar checks y selecciona el Repositorio vinculado. La GitHub App de Autonomy debe estar instalada en ese repositorio.
8. Abre una pull request y confirma que una ejecución comienza cuando la previsualización de Netlify está lista.

Cómo se activa una ejecución

Cuando Netlify envía un webhook deploy_succeeded:

1. Autonomy busca el sitio vinculado por el ID del sitio de Netlify.
2. El contexto del despliegue de Netlify (deploy-preview, production, branch-deploy) se normaliza al vocabulario de Autonomy: preview, production o branch.
3. El contexto se verifica contra los contextos de activación del sitio y la rama contra los filtros de rama.
4. Si hay un objetivo de prueba predeterminado configurado, Autonomy crea una ejecución contra la URL del enlace permanente (permalink) inmutable por despliegue.

Despliegues de PRs desde forks

Cuando un despliegue proviene de una pull request desde un fork, Netlify lo retiene para la aprobación del propietario del equipo y envía un webhook deploy_request_pending. Autonomy registra el evento con estado "pending" — aparece en el panel como esperando aprobación. Una vez que el despliegue es aprobado y tiene éxito, un webhook deploy_succeeded activa la ejecución de la manera habitual.

Sitios protegidos por contraseña

Si el sitio de Netlify tiene protección por contraseña activada (a nivel de sitio o por despliegue), el runner no puede acceder a la previsualización de despliegue. Para configurar el bypass:

1. En Autonomy, abre los ajustes del sitio vinculado.
2. Pega la contraseña del sitio en Secreto de acceso a previsualización.

Autonomy inyecta la contraseña según lo requiere el mecanismo de protección de Netlify. El secreto nunca sale del backend.

Reporte de estado

Netlify no expone una superficie nativa de checks o estado para integraciones de terceros. Autonomy no puede publicar resultados directamente en el panel de Netlify.

Para reportar resultados, vincula un repositorio de GitHub al sitio de Netlify en Autonomy. Cuando está activado, Autonomy publica un check run de GitHub en el commit — el mismo mecanismo que usa la GitHub App. El check aparece en la pull request y puede hacerse un check de estado requerido bajo la protección de rama.

Importante: Si Reportar checks está activado pero no hay ningún repositorio de GitHub vinculado, los resultados solo aparecerán en el panel de Autonomy — no en la pull request ni en ningún lugar de Netlify. El panel muestra una advertencia cuando este es el caso.

Monorepo y múltiples sitios

Un solo repositorio de GitHub puede desplegar múltiples sitios de Netlify. Vincula cada sitio de forma independiente en Autonomy — cada uno tiene su propio objetivo de prueba, entorno, contextos de activación y filtros de rama. Todos los sitios vinculados pueden compartir el mismo repositorio de GitHub vinculado para el reporte de estado.

Cuando Netlify envía un webhook, Autonomy lo asocia al sitio vinculado correcto por el ID del sitio de Netlify.

Variables de entorno (autoalojado)

Solución de problemas

No se inicia ninguna ejecución cuando una previsualización de despliegue está lista

Verifica lo siguiente:

• La cuenta de Netlify está conectada y muestra Activa en Autonomy.
• El sitio de Netlify está vinculado. Autonomy solo supervisa sitios vinculados.
• El sitio está habilitado. Un sitio deshabilitado registra el evento pero omite la ejecución (project disabled).
• El contexto del despliegue está en los contextos de activación del sitio. El deploy-preview de Netlify corresponde a preview, production a production y branch-deploy a branch. Una discrepancia omite con context <x> not enabled.
• La rama coincide con los filtros de rama del sitio. Una discrepancia omite con branch <x> filtered.
• Un caso de prueba o plan de pruebas predeterminado está seleccionado. Sin uno, el evento se omite con no default test target.
• El despliegue alcanzó el estado ready. Un despliegue en estado building o error no activa una ejecución (deployment not ready).
• La URL de previsualización del despliegue está presente. Si el webhook no incluyó una URL de previsualización, el evento se omite con no preview URL.

Un despliegue está atascado como "pending"

Si un despliegue aparece como "pending" en Autonomy y nunca activa una ejecución, es probable que se trate de un despliegue de una PR desde un fork retenido por Netlify para la aprobación del propietario del equipo (deploy_request_pending). Aprueba el despliegue en Netlify — le seguirá un webhook deploy_succeeded que activará la ejecución.

La ejecución no puede acceder a la previsualización de despliegue

La URL de previsualización de despliegue puede estar bloqueada por la protección por contraseña a nivel de sitio. Si la ejecución falla en una página de contraseña, añade la contraseña del sitio como el Secreto de acceso a previsualización.

No aparece ningún check en la pull request

Netlify no tiene una superficie nativa de checks. El reporte de estado requiere:

1. Reportar checks activado en el sitio vinculado.
2. Un Repositorio vinculado seleccionado.
3. La GitHub App de Autonomy instalada en ese repositorio.

Si falta alguno de estos, el estado de reporte del evento es unsupported y no se publica ningún check. Si los checks están activados pero no hay ningún repositorio vinculado, los resultados aparecen solo en el panel de Autonomy.

Ejecuciones duplicadas para el mismo despliegue

Autonomy deduplica por una clave que incluye el ID del despliegue de Netlify y el estado. Un webhook reenviado no produce una segunda ejecución.