UIP-TM warten

uip tm wait fragt eine Testausführung ab, bis sie einen Endstatus erreicht (Passed, Failed, Cancelled usw.) und gibt dann eine einzeilige Zusammenfassung aus. Verwenden Sie diese, um den asynchronen uip tm testsets run in einen blockierenden Schritt in einer CI-Pipeline umzuwandeln.

wait wird als Verb der obersten Ebene unter tm registriert, nicht als Ressource – rufen Sie es als uip tm wait und nicht uip tm executions wait auf.

Zusammenfassung

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

Beachten Sie die globalen Optionen. Im nachfolgenden Abschnitt Beendigungscodes finden Sie weitere Informationen zum domänenspezifischen Verhalten bei Timeouts.

UIP-TM warten

Blockieren Sie, bis die angegebene Ausführung einen Endstatus erreicht, und rufen Sie den Test Manager einmal alle 60 Sekunden ab.

Argumente

Keine.

Optionen

• --execution-id <uuid> (erforderlich) – Ausführung, auf die gewartet werden soll. Rufen Sie es von uip tm testsets run ab.
• --project-key <key> – das besitzende Projekt. Entweder dies oder --test-set-key ist erforderlich.
• --test-set-key <key> – Testsatzschlüssel (z. B DEMO:42); Der Projektschlüssel ist aus dem Präfix abgeleitet.
• --timeout <seconds> – maximale Anzahl von Sekunden. Die Standardeinstellung ist 1800 (30 Minuten). Übergeben Sie 0 um unbegrenzt zu warten.
• -t, --tenant <name> – überschreiben Sie den Mandanten der aktiven Sitzung für diesen Aufruf.
• --log-level <level> – debug, info, warn, error. Standardmäßig auf Information.

Beispiel

uip tm wait \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO \
  --timeout 900

Datenform – wenn die Ausführung vor dem Timeout einen Endzustand erreicht:

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

Status kann ein beliebiger Endstatus-Test Manager-Bericht sein (einschließlich Passed, Failed, Cancelled). „Endstatus erreicht“ ist das Erfolgssignal für wait – das Verb beendet 0 unabhängig davon, ob Tests innerhalb der Ausführung erfolgreich waren oder fehlgeschlagen sind. Um bei Pass/Fehlschlag zu verzweigen, lesen Sie die report get -Ausgabe nach wait -Wiedergabe.

Exitcodes

wait folgt den Standard -Exitcodes für 0, 1 und 3 mit einer domain-spezifischen Wiederverwendung von 2:

Code beenden	Bedeutung
0	Die Ausführung hat innerhalb des Timeouts einen Endstatus erreicht.
1	Abruf fehlgeschlagen (wiederholte API-Fehler, Unterbrechung, Abbruch) – weitere Details finden Sie im Feld Message .
2	Zeitüberschreitung. Das Timeout ist verstrichen, bevor die Ausführung einen Endstatus erreicht hat.
3	Validierungsfehler (false Flag-Wert, fehlende erforderliche Option).

Der Austrittscode 2 ist domänenspezifisch. Der gemeinsame CLI-Vertrag reserviert 2 für AuthenticationError, aber wait verwendet es für das Timeout wieder, sodass Skripte „zu lange gedauert“ und „Abfrage wirklich fehlgeschlagen“ unterscheiden können, ohne Text zu parsen. Das vollständige Muster finden Sie unter Exit-Code-Verhalten auf executions .

Script pattern

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

Zugehörig

• testsets run – erzeugt das ExecutionId , auf das gewartet werden soll.
• report – Zusammenfassung, die gelesen werden soll, sobald wait 0 zurückgibt.
• Ergebnis – JUnit-XML-Export.
• Ausführungswiederholung – führen Sie die fehlgeschlagenen Fälle einer abgeschlossenen Ausführung erneut aus.

Siehe auch

• Test Manager-Übersicht
• Austrittscodes – gemeinsam genutzter Vertrag.
• Skriptingmuster – die Launch-Wait-Verify-Pipeline.