UIP-TM warten

Syntax und Optionen für „uip tm Wait“, das eine Testausführung abfragt, bis sie einen Endstatus erreicht, und eine einzeilige Zusammenfassung ausgibt.

uip tm wait fragt eine Testausführung ab, bis sie einen Endstatus erreicht (Passed, Failed, Cancelled usw.) und gibt dann eine einzeilige Zusammenfassung aus. Dadurch wird das asynchrone uip tm testsets run zu einem blockierenden Schritt in einer CI-Pipeline.

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

Block until the given execution reaches a terminal state, polling Test Manager every 60 seconds (fixed — not configurable).

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> — maximum time to wait, in seconds. Defaults to 1800 (30 minutes). Pass 0 to wait indefinitely.
• --log-level <level> – debug, info, warn, error. Standardmäßig auf Information.

Hinweis:

There is no --poll-interval flag on this command. The poll interval is hardcoded to 60 seconds and cannot be overridden.

Beispiel

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

Datenform – die Ausführung hat vor dem Timeout den Endstatus 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 .

Skriptmuster

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.