- Überblick
- Erste Schritte
- Konzepte
- Verwenden der UiPath CLI
- Anleitungen
- CI/CD-Rezepte
- Befehlsreferenz
- Überblick
- Exitcodes
- Globale Optionen
- UIP-codierter Agent
- UIP-Dokumentation
- Add-Test-Data-Entität
- Add-Test-Data-Queue
- Add-Test-Data-Variation
- Analysieren
- Erstellen
- Ein Projekt erstellen
- Diff
- Suchaktivitäten
- Get-Analyse-Regeln
- get-standard-aktivität-xaml
- Fehler abrufen
- Manuelle-Testfälle erhalten
- Manuelle-Testschritte erhalten
- Get-Versionen
- Beispiel für einen Workflow abrufen
- Anwendung anzeigen
- Anzeigeelement
- Inspektionspaket
- install-data-fabric-entities
- Pakete installieren oder aktualisieren
- list-data-fabric-entities
- Beispiele für Listenworkflows
- Packen
- restore
- Ausführungsdatei installieren
- Suchvorlagen
- Studio starten
- Ausführung anhalten
- UIA
- UIP-Ablaufverfolgungen
- Migration
- Referenz und Support
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 <ms>] [--poll-interval <ms>]
uip tm wait --execution-id <uuid> (--project-key <key> | --test-set-key <key>)
[--timeout <ms>] [--poll-interval <ms>]
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 in einem konfigurierbaren Intervall ab.
Argumente
Keine.
Optionen
--execution-id <uuid>(erforderlich) – Ausführung, auf die gewartet werden soll. Rufen Sie es vonuip tm testsets runab.--project-key <key>– das besitzende Projekt. Entweder dies oder--test-set-keyist erforderlich.--test-set-key <key>– Testsatzschlüssel (z. B.DEMO:42); Der Projektschlüssel ist aus dem Präfix abgeleitet.--timeout <ms>– maximale Wartezeit in Millisekunden. Die Standardeinstellung ist1800000(30 Minuten). Übergeben Sie0um unbegrenzt zu warten.--poll-interval <ms>– Wie oft der Ausführungsstatus in Millisekunden abgefragt werden soll. Die Standardeinstellung ist60000(60 Sekunden).-t, --tenant <name>– überschreiben Sie den Mandanten der aktiven Sitzung für diesen Aufruf.--log-level <level>–debug,info,warn,error. Standardmäßig aufInformation.
Beispiel
# wait up to 15 minutes, polling every 30 seconds
uip tm wait \
--execution-id a1b2c3d4-0000-0000-0000-000000000001 \
--project-key DEMO \
--timeout 900000 \
--poll-interval 30000
# wait up to 15 minutes, polling every 30 seconds
uip tm wait \
--execution-id a1b2c3d4-0000-0000-0000-000000000001 \
--project-key DEMO \
--timeout 900000 \
--poll-interval 30000
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"
}
}
{
"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 1800000 \
--poll-interval 30000; then
case $? in
2) echo "timed out" >&2; exit 2 ;;
*) echo "wait failed" >&2; exit 1 ;;
esac
fi
if ! uip tm wait \
--execution-id "$id" \
--project-key DEMO \
--timeout 1800000 \
--poll-interval 30000; 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
wait0zurü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.