Builds mobiles

Les exécutions mobiles ont besoin d'un build de votre application. Placez-le sur une cible d'environnement pour le réutiliser à chaque exécution jusqu'à la version suivante, ou téléversez-le depuis la CI et lancez directement des exécutions avec lui.

Quoi téléverser

Pour iOS (bientôt disponible), Autonomy a besoin d'un build pour simulateur, car les exécutions utilisent des simulateurs iOS. Un .ipa signé construit pour appareil physique ne peut pas s'exécuter. Pour Android, .apk et .aab fonctionnent tous les deux ; les exécutions installent le build sur un émulateur et l'ouvrent par son nom de package. Les builds mobiles peuvent atteindre 512 Mo. Chaque téléversement passe par un contrôle de sécurité avant qu'une exécution puisse l'utiliser.

Construire pour le simulateur iOS

Pour un projet Xcode, construisez avec xcodebuild :

xcodebuild -workspace ios/MyApp.xcworkspace \
-scheme MyApp \
-configuration Release \
-sdk iphonesimulator \
-destination 'generic/platform=iOS Simulator' \
-derivedDataPath ios/build \
CODE_SIGNING_ALLOWED=NO \
build

Le bundle est produit dans ios/build/Build/Products/Release-iphonesimulator/MyApp.app. Pour les projets Expo ou React Native, exécutez d'abord npx expo prebuild --platform ios, puis la même commande xcodebuild sur le workspace généré.

Compressez le bundle avant de le téléverser, avec le .app à la racine de l'archive. -y conserve les liens symboliques.

cd ios/build/Build/Products/Release-iphonesimulator
zip -qry MyApp.app.zip MyApp.app

Construire pour Android

Pour un projet Android, construisez un APK de debug. Les APK de debug s'installent sur les émulateurs sans signature supplémentaire.

cd android
./gradlew assembleDebug

L'APK est produit dans android/app/build/outputs/apk/debug/app-debug.apk. Pour les projets Expo ou React Native, exécutez d'abord npx expo prebuild --platform android, puis la même commande Gradle sur le projet généré.

Pour un App Bundle, exécutez ./gradlew bundleDebug et récupérez le .aab dans android/app/build/outputs/bundle/debug/.

Téléverser depuis le tableau de bord

1. Ouvrez le projet et cliquez sur Environments, puis ouvrez l'environnement. Les propriétaires et les administrateurs peuvent modifier les environnements.
2. Sous la cible iOS ou Android, choisissez Upload et déposez le zip du .app, le .apk ou le .aab, ou cliquez pour parcourir vos fichiers.
3. Attendez « Uploaded and scanned », puis enregistrez l'environnement.
4. Exécutez une fois un cas de test sur cet environnement, pour confirmer que le build s'ouvre et que la première étape peut être atteinte.

Pour utiliser un build que votre CI publie déjà, choisissez plutôt URL et collez un lien de téléchargement direct. Les exécutions utilisent le build vers lequel pointait le lien au moment où vous l'avez enregistré. Quand votre CI publie un nouveau build au même lien, enregistrez à nouveau le lien, ou téléversez le build depuis la CI comme ci-dessous. Voir Environnements.

Téléverser avec l'API

Utilisez l'API depuis la CI quand le build est propre à ce pipeline et ne doit pas remplacer le build de l'environnement. Il faut trois appels, puis l'identifiant de stockage du build est transmis à run.trigger. Authentifiez-vous avec une clé API d'organisation commençant par aut_, issue de Organization → API keys (propriétaires et administrateurs).

1. POST /api/artifacts/upload-url avec platform (ios ou android), fileName, contentType et declaredBytes (la taille du fichier en octets). La réponse contient uploadUrl, storageId, method ("PUT"), intentId et expiresAt.
2. PUT du fichier vers uploadUrl avec le même Content-Type.
3. POST /api/artifacts/scan avec storageId et intentId. Ne lancez les exécutions que si status vaut "clean" ; sinon, findings indique le problème.

set -euo pipefail
API=https://api.autonomyqa.com
FILE=ios/build/Build/Products/Release-iphonesimulator/MyApp.app.zip

UPLOAD=$(curl -fsS -X POST "$API/api/artifacts/upload-url" \
-H "Authorization: Bearer $AUTONOMY_API_KEY" \
-H "Content-Type: application/json" \
-d "$(jq -n --argjson bytes "$(wc -c < "$FILE" | tr -d ' ')" \
  '{platform: "ios", fileName: "MyApp.app.zip", contentType: "application/zip", declaredBytes: $bytes}')")
STORAGE_ID=$(jq -r '.storageId' <<< "$UPLOAD")
INTENT_ID=$(jq -r '.intentId' <<< "$UPLOAD")

curl -fsS -X PUT "$(jq -r '.uploadUrl' <<< "$UPLOAD")" \
-H "Content-Type: application/zip" \
--data-binary "@$FILE"

SCAN=$(curl -fsS -X POST "$API/api/artifacts/scan" \
-H "Authorization: Bearer $AUTONOMY_API_KEY" \
-H "Content-Type: application/json" \
-d "$(jq -n --arg s "$STORAGE_ID" --arg i "$INTENT_ID" '{storageId: $s, intentId: $i}')")
jq -e '.status == "clean"' <<< "$SCAN" > /dev/null

Lancez ensuite les exécutions avec POST /api/v1/run.trigger. Indiquez dans le corps exactement l'un des deux champs testPlanId (un plan de test : une exécution par cas de test) ou testCaseId (un seul cas de test), le build comme cible explicite, et un idempotencyKey. Une nouvelle tentative avec la même clé renvoie les mêmes exécutions au lieu d'en lancer de nouvelles.

TRIGGER=$(curl -fsS -X POST "$API/api/v1/run.trigger" \
-H "Authorization: Bearer $AUTONOMY_API_KEY" \
-H "Content-Type: application/json" \
-d "$(jq -n --arg plan "$AUTONOMY_TEST_PLAN_ID" --arg s "$STORAGE_ID" \
  --arg key "my-ci:$BUILD_ID:ios" \
  '{
    testPlanId: $plan,
    platforms: ["ios"],
    targets: { ios: { bundleId: "com.example.MyApp", storageId: $s, sourceMode: "upload", fileName: "MyApp.app.zip" } },
    branch: "main",
    deployment: { provider: "my-ci", branch: "main", commitSha: "abc123" },
    idempotencyKey: $key
  }')")
jq -r '.runIds[]' <<< "$TRIGGER"

La réponse est { runIds, planGroupRunId?, environment? }. Pour Android, envoyez platform: "android" et contentType: "application/vnd.android.package-archive", puis déclenchez avec targets.android et packageName au lieu de bundleId.

Pour exécuter plutôt sur un environnement enregistré, envoyez environmentSlug à la place de targets : l'exécution utilise le build et les valeurs de cet environnement. Une cible explicite n'a pas d'environnement : les étapes qui utilisent {{env.NAME}} se terminent donc en Couldn't start. Si votre CI vous fournit déjà un lien HTTPS vers le build, sautez le téléversement et envoyez artifactUrl avec sourceMode: "url".

Suivre les exécutions

Appelez POST /api/v1/run.get avec runId, le cursor de la réponse précédente et waitMs jusqu'à 25000. Chaque appel attend que l'exécution évolue ; timedOut: true signifie seulement que rien n'a encore changé. Arrêtez-vous quand status vaut passed, failed, couldnt_start ou cancelled.

Pour conditionner un pipeline, ne le laissez réussir que si toutes les exécutions sont passed (une réussite flaky compte). failed le fait échouer ; ouvrez l'exécution pour voir quelle étape a échoué et pourquoi. couldnt_start le fait aussi échouer, mais cela signifie que l'environnement n'a pas pu être testé, par exemple parce que le build ne s'est pas installé, et non que votre application est cassée.

Les recettes de CI regroupent tout cela, téléversement, lancement et suivi, dans un seul script .ci/autonomy.sh : voir GitHub Actions, GitLab CI, Jenkins, Bitrise et CircleCI. Les champs et les erreurs sont décrits dans la référence de l'API et dans Exécutions et preuves.

Limites

• iOS s'exécute uniquement sur des simulateurs. L'appareil photo, Face ID, Touch ID et tout parcours qui nécessite un build signé pour appareil physique ne fonctionnent pas.
• Android s'exécute sur des émulateurs. Les fonctions purement matérielles comme le NFC, l'empreinte digitale et un vrai appareil photo ne sont pas disponibles.

Dépannage

Le téléversement iOS est refusé

Vérifiez que le build a utilisé -sdk iphonesimulator et une destination de simulateur, et que vous avez téléversé un .zip, un .tgz ou un .tar.gz contenant le .app. Un build pour iphoneos est un build pour appareil physique.

Le téléversement Android est refusé

Seuls les fichiers .apk et .aab sont acceptés.

La demande d'URL de téléversement renvoie 400

declaredBytes (un nombre) et contentType sont obligatoires. La demande de contrôle nécessite à la fois storageId et intentId, issus de la réponse à la demande d'URL de téléversement.

L'exécution a utilisé un build plus ancien

Une exécution avec environmentSlug utilise le build de l'environnement, et non celui que vous venez de téléverser. Envoyez le nouveau build comme cible explicite, ou mettez d'abord à jour la cible de l'environnement.