Expo EAS

L'intégration Expo EAS reçoit des webhooks de fin de build depuis EAS Build. Quand un build se termine avec succès, Autonomy télécharge l'artefact et exécute le cas de test ou le plan de test configuré sur un simulateur iOS ou un émulateur Android. Le statut est rapporté comme un check run GitHub sur le commit si un dépôt GitHub est lié.

Ce qu'elle fait

• Reçoit un webhook quand un build EAS se termine.
• Télécharge l'artefact du build (archive .app pour iOS, .apk pour Android).
• Exécute le cas de test ou le plan de test configuré sur l'artefact sur la plateforme correspondante.
• Rapporte le résultat comme un check run GitHub sur le commit quand un dépôt GitHub est lié.
• Les artefacts .aab (Android App Bundle) ne peuvent pas être installés sur un émulateur — seuls les builds .apk sont testables. Un artefact .aab est omis avec artifact kind aab is not installable.
• Les formats d'artefact non reconnus (ni .app, .apk, .ipa, ni .aab) sont omis avec artifact format not recognized: <ext>.
• Les URLs d'artefacts EAS expirent après 30 jours. Autonomy télécharge l'artefact au moment du déclenchement ; les URLs expirées sont omises avec build artifact expired.

Configuration

1. Ouvrez Paramètres → Intégrations dans le tableau de bord Autonomy.
2. Cliquez sur Connecter sur la carte Expo EAS. Collez un jeton d'accès robot Expo. Expo utilise l'authentification par jeton — il n'y a pas de flux OAuth.
3. Cliquez sur Lier une app. Autonomy liste les apps Expo visibles pour votre compte — choisissez celle que vous voulez tester. Le webhook est enregistré automatiquement au moment du lien.
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. Sélectionnez quelles plateformes (iOS, Android ou les deux) doivent déclencher des exécutions.
7. Pour rapporter les résultats comme un 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.

Enregistrement du webhook

Le webhook est enregistré automatiquement lorsque vous liez une app. Si l'enregistrement automatique échoue — par exemple parce que le jeton d'accès n'a pas la permission de gérer les webhooks — un secours est disponible :

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

Pour trouver l'URL de callback et le secret du webhook :

1. Dans Autonomy, ouvrez les paramètres de l'app liée.
2. Dépliez Secours manuel (eas webhook:create). Copiez l'URL de callback et le Secret du webhook.
3. Exécutez la commande eas webhook:create ci-dessus avec ces valeurs.

Le secret du webhook est généré par Autonomy quand vous liez l'app. Il sert à vérifier la signature de chaque webhook entrant.

Filtres de branche

Les filtres de branche ne sont pas disponibles pour Expo EAS. Les webhooks EAS Build ne transportent pas de nom de branche, les filtres de branche ne peuvent donc pas être évalués. Le contrôle de filtre de branche est masqué dans le tableau de bord, et le backend rejette les filtres de branche non vides pour les projets Expo.

Profils de build pour des artefacts testables

Autonomy a besoin d'un profil de build dans eas.json qui produit des artefacts installables :

• iOS : définissez simulator à true pour produire un build .app Simulateur au lieu d'un .ipa signé. Un .ipa pour appareil ne peut pas être installé sur un Simulateur.
• Android : définissez buildType à apk pour produire un .apk au lieu d'un .aab. Un .aab ne peut pas être installé sur un émulateur.

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

Comment une exécution est déclenchée

Quand EAS envoie un webhook BUILD avec un statut finished :

1. Autonomy cherche l'app liée par l'ID du projet Expo.
2. Le contexte de build (preview, production ou branch) est vérifié par rapport aux contextes de déclenchement configurés de l'app.
3. Les filtres de branche ne sont pas appliqués — les webhooks EAS Build ne transportent pas de branche.
4. La plateforme du build (iOS ou Android) est vérifiée par rapport aux plateformes configurées de l'app.
5. L'URL et le type d'artefact sont validés. Les types non installables (.aab) et les formats non reconnus sont omis.
6. Si l'URL d'artefact a expiré (>30 jours), l'événement est omis.
7. Si une cible de test par défaut est configurée, Autonomy crée une exécution avec l'artefact comme cible mobile.

L'exécution reçoit l'artefact comme source URL — le runner le télécharge directement. Comme les URLs d'artefacts EAS expirent après 30 jours, le téléchargement se fait au moment du déclenchement.

Rapport de statut

Expo n'a pas de surface native de checks. Autonomy ne peut pas publier de résultats directement dans le tableau de bord Expo.

Pour rapporter des résultats, liez un dépôt GitHub à l'app Expo dans Autonomy. Quand c'est activé, Autonomy publie un check run GitHub sur le commit — le même mécanisme utilisé pour Netlify et 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 Expo. Le tableau de bord affiche un avertissement lorsque c'est le cas.

Exemple de EAS Workflow

Si vous utilisez les EAS Workflows, ajoutez .eas/workflows/autonomy-e2e.yml pour construire des artefacts testables. Dans le mode webhook par défaut, le webhook BUILD se déclenche automatiquement à la fin de chaque build — aucun job de déclenchement n'est nécessaire dans le 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.

Pour un déclenchement explicite (en contournant le webhook), régénérez le workflow avec dispatchMode: "explicit". Cela ajoute un job trigger_autonomy qui effectue un POST sur l'API Autonomy une fois les builds terminés. Le mode explicite nécessite trois secrets EAS :

• AUTONOMY_API_KEY — Clé d'API programmatique Autonomy
• AUTONOMY_TEST_PLAN_ID — ID de document Convex du plan de test à exécuter
• AUTONOMY_ENVIRONMENT_SLUG — Slug d'environnement Autonomy (ex. "staging")

Définissez-les avec :

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

L'intégration par webhook et l'approche workflow sont indépendantes — utilisez celle qui convient à votre pipeline. Le chemin webhook est plus simple (pas de scripts shell), tandis que le chemin de workflow explicite vous donne le contrôle sur le moment exact du déclenchement.

Monorepo et apps multiples

Un seul compte Expo peut avoir plusieurs apps. Liez chaque app indépendamment dans Autonomy — chacune a sa propre cible de test, son environnement et ses plateformes. Toutes les apps liées peuvent partager le même dépôt GitHub lié pour le rapport de statut.

Dépannage

Aucune exécution ne démarre quand un build EAS se termine

Vérifiez les points suivants :

• Le compte Expo est connecté et affiche Actif dans Autonomy.
• L'app Expo est liée. Autonomy ne surveille que les apps liées.
• L'app est activée. Une app désactivée enregistre l'événement mais omet l'exécution (project disabled).
• Le webhook est enregistré. Vérifiez la section Webhook dans les paramètres de l'app — elle doit afficher Enregistré. Sinon, utilisez le secours manuel : exécutez eas webhook:create avec l'URL et le secret du panneau de configuration.
• Le statut du build est finished. Un build en état in-progress ou errored ne déclenche pas d'exécution (deployment not ready).
• Le contexte du build correspond aux contextes de déclenchement configurés de l'app. Une non-correspondance omet l'événement avec context <x> not enabled.
• 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 build a produit un artefact téléchargeable. Si aucune URL d'artefact n'est présente, l'événement est omis avec no build artifact.

L'exécution échoue à installer le build

• iOS : confirmez que le profil de build EAS définit ios.simulator: true. Un .ipa signé pour un appareil physique ne peut pas être installé sur un Simulateur.
• Android : confirmez que le profil de build EAS définit android.buildType: "apk". Un .aab ne peut pas être installé sur un émulateur. Autonomy omet les artefacts .aab avec artifact kind aab is not installable.

Le format d'artefact n'est pas reconnu

Si le build produit un fichier avec une extension qu'Autonomy ne reconnaît pas (ni .app, .apk, .ipa, ni .aab), l'événement est omis avec artifact format not recognized: <ext>. Vérifiez le profil de build EAS pour vous assurer qu'il produit un artefact standard.

L'URL d'artefact est expirée

Les URLs d'artefacts EAS expirent après 30 jours. L'événement est omis avec build artifact expired. Déclenchez un nouveau build EAS — Autonomy recevra un nouveau webhook avec une URL valide.

Aucun check n'apparaît sur la pull request

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

1. Rapporter les checks activé sur l'app liée.
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 n'apparaissent que dans le tableau de bord Autonomy.