attendre tm uip

Syntaxe et options de `uip tm wait`, qui interroge une exécution de test jusqu'à ce qu'elle atteigne un état terminal et imprime un résumé sur une ligne.

uip tm wait interroge une exécution de test jusqu'à ce qu'elle atteigne un état terminal (Passed, Failed, Cancelled, etc.), puis imprime un résumé en une ligne. Il transforme l' uip tm testsets run asynchrone en étape de blocage dans un pipeline CI.

wait est enregistré en tant que verbe de haut niveau sous tm, et non en tant que ressource. Invoquez-le en tant que uip tm wait, et non uip tm executions wait.

Synthèse

uip tm wait --execution-id <uuid> (--project-key <key> | --test-set-key <key>)
            [--timeout <seconds>]

Respecte les options globales. Consultez la section Codes de sortie ci-dessous pour connaître le comportement spécifique au domaine en cas de délai d'expiration.

attendre tm uip

Bloquer jusqu’à ce que l’exécution donnée atteigne un état terminal, en interrogeant Test Manager toutes les 60 secondes (fixé — non configurable).

Arguments

Aucun

Options

• --execution-id <uuid> (requis) : exécution à attendre. Obtenez-le à partir de uip tm testsets run.
• --project-key <key> — propriétaire du projet. Il est obligatoire de spécifier soit ceci, soit --test-set-key .
• --test-set-key <key> — clé de l'ensemble de tests (par exemple, DEMO:42); la clé du projet est dérivée du préfixe.
• --timeout <seconds> — temps d'attente maximal, en secondes. La valeur par défaut est 1800 (30 minutes). Transmettez 0 pour attendre indéfiniment.
• --log-level <level> — debug, info, warn, error La valeur par défaut est Information.

Remarque :

Il n'y a pas d'indicateur --poll-interval sur cette commande. L'intervalle d'interrogation est codé en dur sur 60 secondes et ne peut pas être remplacé.

Exemple

# wait up to 15 minutes
uip tm wait \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO \
  --timeout 900

Format de données — l'exécution a atteint l'état terminal avant le délai d'expiration

{
  "Code": "WaitComplete",
  "Data": {
    "ExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
    "Status": "Passed",
    "EndTime": "2025-04-15T10:32:11Z",
    "Duration": "00:02:11"
  }
}

Status peut correspondre à n’importe quel rapport de Test Manager dans l’état terminal (y compris Passed, Failed, Cancelled). « A atteint l'état terminal» est le signal de réussite de wait — le verbe quitte 0 que les tests à l'intérieur de l'exécution aient réussi ou échoué. Pour se ramifier sur réussite/échec, lisez la sortie report get après wait retours.

Codes de sortie

wait suit les codes de sortie standard pour 0, 1 et 3, avec une réutilisation spécifique au domaine de 2:

Code de sortie	Signification
0	L'exécution a atteint un état terminal dans le délai d'expiration.
1	Échec de l’interrogation (erreurs d’API répétées, interruption, abandon) - voir le champ Message pour plus de détails.
2	Expiration du délai. Le délai d’attente s’est écoulé avant que l’exécution n’atteigne l’état terminal.
3	Erreur de validation (valeur d’indicateur incorrecte, option requise manquante).

Le code de sortie 2 est spécifique au domaine. Le contrat CLI partagé réserve 2 pour AuthenticationError, mais wait le réutilise pour le délai d'attente afin que les scripts puissent distinguer « a pris trop de temps » de « l'interrogation a réellement échoué » sans analyser le texte. Voir Comportement du code de sortie sur executions pour le modèle complet.

Modèle de script

if ! uip tm wait \
    --execution-id "$id" \
    --project-key DEMO \
    --timeout 1800; then
  case $? in
    2) echo "timed out" >&2; exit 2 ;;
    *) echo "wait failed" >&2; exit 1 ;;
  esac
fi

Associé

• exécution des ensembles de tests — produit le ExecutionId à attendre.
• rapport — résumé à lire une fois que wait renvoie 0.
• résultat — Exportation XML JUnit.
• exécutions réessayer — réexécuter les cas ayant échoué d’une exécution terminée.

Voir également

• Vue d’ensemble de Test Manager
• Codes de sortie — contrat partagé.
• Modèles de script — le pipeline Launch-Wait-Verify.