Expo EAS

La integración de Expo EAS recibe webhooks de finalización de builds de EAS Build. Cuando un build termina con éxito, Autonomy descarga el artefacto y ejecuta el caso de prueba o plan de pruebas configurado en un simulador de iOS o emulador de Android. El estado se reporta como un check run de GitHub en el commit si hay un repositorio de GitHub vinculado.

Qué hace

• Recibe un webhook cuando un build de EAS finaliza.
• Descarga el artefacto del build (archivo .app para iOS, .apk para Android).
• Ejecuta el caso de prueba o plan de pruebas configurado contra el artefacto en la plataforma correspondiente.
• Informa el resultado como un check run de GitHub en el commit cuando hay un repositorio de GitHub vinculado.
• Los artefactos .aab (Android App Bundle) no se pueden instalar en un emulador — solo los builds .apk son probables. Un artefacto .aab se omite con artifact kind aab is not installable.
• Los formatos de artefactos no reconocidos (ni .app, .apk, .ipa ni .aab) se omiten con artifact format not recognized: <ext>.
• Las URLs de artefactos de EAS expiran después de 30 días. Autonomy descarga el artefacto en el momento de la activación; las URLs expiradas se omiten con build artifact expired.

Configuración

1. Abre Ajustes → Integraciones en el panel de Autonomy.
2. Haz clic en Conectar en la tarjeta de Expo EAS. Pega un token de acceso robot de Expo. Expo usa autenticación basada en token — no hay flujo OAuth.
3. Haz clic en Vincular app. Autonomy lista las apps de Expo visibles para tu cuenta — elige la que quieras probar. El webhook se registra automáticamente al vincular.
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. Selecciona qué plataformas (iOS, Android o ambas) deben activar ejecuciones.
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.

Registro del webhook

El webhook se registra automáticamente al vincular una app. Si el registro automático falla — por ejemplo, porque el token de acceso no tiene permiso para gestionar webhooks — hay una alternativa manual disponible:

eas webhook:create --event BUILD --url <url-de-callback> --secret <secreto>

Para encontrar la URL de callback y el secreto del webhook:

1. En Autonomy, abre los ajustes de la app vinculada.
2. Despliega Alternativa manual (eas webhook:create). Copia la URL de callback y el Secreto del webhook.
3. Ejecuta el comando eas webhook:create de arriba con esos valores.

El secreto del webhook es generado por Autonomy cuando vinculas la app. Se usa para verificar la firma de cada webhook entrante.

Filtros de rama

Los filtros de rama no están disponibles para Expo EAS. Los webhooks de EAS Build no incluyen el nombre de la rama, por lo que no se pueden evaluar los filtros de rama. El control de filtro de rama está oculto en el panel, y el backend rechaza los filtros de rama no vacíos para proyectos de Expo.

Perfiles de build para artefactos probables

Autonomy necesita un perfil de build en eas.json que produzca artefactos instalables:

• iOS: establece simulator en true para producir un build .app de Simulador en lugar de un .ipa firmado. Un .ipa de dispositivo no se puede instalar en un Simulador.
• Android: establece buildType en apk para producir un .apk en lugar de un .aab. Un .aab no se puede instalar en un emulador.

1{2  "build": {3    "autonomy-e2e": {4      "withoutCredentials": true,5      "ios": {6        "simulator": true7      },8      "android": {9        "buildType": "apk"10      }11    }12  }13}

Cómo se activa una ejecución

Cuando EAS envía un webhook BUILD con estado finished:

1. Autonomy busca la app vinculada por el ID del proyecto de Expo.
2. El contexto del build (preview, production o branch) se verifica contra los contextos de activación configurados de la app.
3. No se aplican filtros de rama — los webhooks de EAS Build no incluyen rama.
4. La plataforma del build (iOS o Android) se verifica contra las plataformas configuradas de la app.
5. La URL y el tipo de artefacto se validan. Los tipos no instalables (.aab) y los formatos no reconocidos se omiten.
6. Si la URL del artefacto ha expirado (>30 días), el evento se omite.
7. Si hay un objetivo de prueba predeterminado configurado, Autonomy crea una ejecución con el artefacto como objetivo móvil.

La ejecución recibe el artefacto como una fuente URL — el runner lo descarga directamente. Como las URLs de artefactos de EAS expiran después de 30 días, la descarga ocurre en el momento de la activación.

Reporte de estado

Expo no tiene una superficie nativa de checks. Autonomy no puede publicar resultados directamente en el panel de Expo.

Para reportar resultados, vincula un repositorio de GitHub a la app de Expo en Autonomy. Cuando está activado, Autonomy publica un check run de GitHub en el commit — el mismo mecanismo usado para Netlify y 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 Expo. El panel muestra una advertencia cuando este es el caso.

Ejemplo de EAS Workflow

Si usas EAS Workflows, añade .eas/workflows/autonomy-e2e.yml para construir artefactos probables. En el modo predeterminado de webhook, el webhook BUILD se activa automáticamente cuando se completa cada build — no se necesita ningún trabajo de activación en el workflow.

name: 'Autonomy E2E — My App'

on:
push:
  branches:
    - 'main'
pull_request:
  branches:
    - '*'

jobs:
build_ios:
  name: Build iOS for Autonomy
  type: build
  params:
    platform: ios
    profile: 'autonomy-e2e'

build_android:
  name: Build Android for Autonomy
  type: build
  params:
    platform: android
    profile: 'autonomy-e2e'

# ─── No trigger job needed ───
# The EAS BUILD webhook fires automatically when each build completes.
# Autonomy ingests the webhook, creates QA runs, and reports back.

Para la activación explícita (evitando el webhook), vuelve a generar el workflow con dispatchMode: "explicit". Esto añade un trabajo trigger_autonomy que hace un POST a la API de Autonomy después de que se completan los builds. El modo explícito requiere tres secretos de EAS:

• AUTONOMY_API_KEY — Clave de API programática de Autonomy
• AUTONOMY_TEST_PLAN_ID — ID de documento Convex del Plan de pruebas a ejecutar
• AUTONOMY_ENVIRONMENT_SLUG — Slug de entorno de Autonomy (ej. "staging")

Establécelos con:

eas secret:create --name AUTONOMY_API_KEY --value <tu-clave-api>
eas secret:create --name AUTONOMY_TEST_PLAN_ID --value <id-plan>
eas secret:create --name AUTONOMY_ENVIRONMENT_SLUG --value <slug>

La integración por webhook y el enfoque de workflow son independientes — usa el que se ajuste a tu pipeline. El camino del webhook es más simple (sin scripts de shell), mientras que el camino explícito de workflow te da control sobre exactamente cuándo se activa la ejecución.

Monorepo y múltiples apps

Una sola cuenta de Expo puede tener múltiples apps. Vincula cada app de forma independiente en Autonomy — cada una tiene su propio objetivo de prueba, entorno y plataformas. Todas las apps vinculadas pueden compartir el mismo repositorio de GitHub vinculado para el reporte de estado.

Solución de problemas

No se inicia ninguna ejecución cuando un build de EAS finaliza

Verifica lo siguiente:

• La cuenta de Expo está conectada y muestra Activa en Autonomy.
• La app de Expo está vinculada. Autonomy solo supervisa apps vinculadas.
• La app está habilitada. Una app deshabilitada registra el evento pero omite la ejecución (project disabled).
• El webhook está registrado. Revisa la sección Webhook en los ajustes de la app — debe mostrar Registrado. Si no, usa la alternativa manual: ejecuta eas webhook:create con la URL y el secreto del panel de ajustes.
• El estado del build es finished. Un build en estado in-progress o errored no activa una ejecución (deployment not ready).
• El contexto del build coincide con los contextos de activación configurados de la app. Una discrepancia omite con context <x> not enabled.
• Un caso de prueba o plan de pruebas predeterminado está seleccionado. Sin uno, el evento se omite con no default test target.
• El build produjo un artefacto descargable. Si no hay URL de artefacto presente, el evento se omite con no build artifact.

La ejecución falla al instalar el build

• iOS: confirma que el perfil de build de EAS establece ios.simulator: true. Un .ipa firmado para un dispositivo físico no se puede instalar en un Simulador.
• Android: confirma que el perfil de build de EAS establece android.buildType: "apk". Un .aab no se puede instalar en un emulador. Autonomy omite los artefactos .aab con artifact kind aab is not installable.

El formato del artefacto no se reconoce

Si el build produce un archivo con una extensión que Autonomy no reconoce (que no sea .app, .apk, .ipa o .aab), el evento se omite con artifact format not recognized: <ext>. Revisa el perfil de build de EAS para asegurarte de que produce un artefacto estándar.

La URL del artefacto ha expirado

Las URLs de artefactos de EAS expiran después de 30 días. El evento se omite con build artifact expired. Activa un nuevo build de EAS — Autonomy recibirá un nuevo webhook con una URL válida.

No aparece ningún check en la pull request

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

1. Reportar checks activado en la app vinculada.
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 solo aparecen en el panel de Autonomy.