Exitcodes

Jeder uip -Aufruf endet mit einem numerischen Exitcode. Skripte und CI-Pipelines verzweigen sich auf diese Codes, um zwischen Erfolg, einem vorübergehenden Fehler, der einen erneuten Versuch wert ist, einem Anmeldeinformationsproblem, das menschliche Aufmerksamkeit erfordert, und einem Missbrauch der Befehlszeile zu unterscheiden.

Vertrag

Der Exitcode wird durch das Feld Result im Ausgabeumschlag des Befehls bestimmt. Der Host ordnet jeden Result -Wert einem einzelnen Exitcode zu:

Code beenden	Result Wert(e)	Bedeutung
0	Success	Der Befehl wurde abgeschlossen, und seine Absicht wurde erreicht.
1	Failure, ConfigError	Generischer Fehler oder ein Konfigurationsproblem, das die CLI vor dem Erreichen des Servers erkennen kann (fehlender Mandant, fehlende Datei auf dem Datenträger usw.).
2	AuthenticationError	Die Sitzung ist nicht authentifiziert, das Token ist abgelaufen oder der Orchestrator hat die Anmeldeinformationen abgelehnt (401/403).
3	ValidationError	Der Befehl wurde mit ungültiger Eingabe aufgerufen – unbekanntes Flag, Flag mit falschem Wert, sich gegenseitig ausschließende Flags, falsch formatiertes --output-filter usw.
4	TimeoutError	Ein Vorgang mit langer Ausführungszeit hat seine Frist überschritten. Reserviert für zukünftige Verwendung – heute gibt kein Befehl dies aus, aber der Vertrag ist stabil, sodass Skripts, die dafür geschrieben wurden, weiterhin funktionieren.

Des Weiteren:

Code beenden	Quelle	Bedeutung
130	Shell-Konvention (128 + SIGINT)	Der Benutzer hat eine interaktive Eingabeaufforderung abgebrochen (Strg+C während uip login, uip skills install, uip completion usw.).

Die UiPath CLI gibt keine anderen Exit-Codes aus. Ein Wert außerhalb dieser Tabelle weist auf eine ungewöhnliche Beendigung hin – ein unerwarteter Absturz, ein untergeordneter Runaway-Prozess oder die Shell, die ein Signal meldet – und sollte untersucht werden, nicht einen Musterabgleich.

Stabilität

• 0, 1, 2, 3 sind stabil in einer MaJOR-Version. Ein Befehl, der mit 3 (Validierung) für eine bestimmte Eingabe beendet wird, wird weiterhin mit 3 über Minor- und PATCH-erfahrungen beendet.
• 4 ist reserviert. Eine zukünftige MINI-Version könnte damit beginnen, sie von Befehlen mit langer Ausführungszeit auszugeben; Skripte, die 4 bereits als „Timeout“ behandeln, funktionieren weiter.
• Neue Codes können in einer MaJOR-Version hinzugefügt werden, wobei dies in den Versionshinweisen angekündigt wird. Der aktuelle Satz deckt jeden Fehlermodus ab, den UiPath CLI 1.x benötigt.

Weitere Informationen finden Sie unter Versionierung und Stabilität .

Lesen des Exit-Codes in Skripts

bash/sh/zsh

uip or folders list
case $? in
  0)   echo "ok" ;;
  1)   echo "command failed" ;;
  2)   echo "not authenticated — run uip login" ;;
  3)   echo "bad input — check flags" ;;
  4)   echo "timed out" ;;
  130) echo "cancelled by user" ;;
  *)   echo "unexpected exit: $?" ;;
esac

set -e (oder set -o errexit) bricht das Skript bei jedem Beenden ungleich Null ab. Dies ist der allgemeine Standardwert für CI; kombinieren Sie es mit trap oder mit der Behandlung pro Befehl, wenn Sie zwischen Codes unterscheiden müssen:

set -euo pipefail

if ! uip or folders list --output json > folders.json; then
  case $? in
    2)  uip login ; uip or folders list --output json > folders.json ;;
    *)  exit $? ;;
  esac
fi

PowerShell

uip or folders list
switch ($LASTEXITCODE) {
    0   { Write-Host "ok" }
    1   { Write-Host "command failed" }
    2   { Write-Host "not authenticated" }
    3   { Write-Host "bad input" }
    4   { Write-Host "timed out" }
    130 { Write-Host "cancelled" }
    default { Write-Host "unexpected exit: $LASTEXITCODE" }
}

GitHub-Aktionen

Bei jedem Beenden ungleich Null in einem run: -Schritt schlägt der Auftrag standardmäßig fehl. Um auf bestimmte Codes zu verzweigen, erfassen Sie den Code explizit:

- name: Query Orchestrator
  id: folders
  run: |
    uip or folders list --output json > folders.json
    echo "exit_code=$?" >> "$GITHUB_OUTPUT"
  continue-on-error: true

- name: Re-authenticate if expired
  if: steps.folders.outputs.exit_code == '2'
  run: uip login --client-id env.UIPATH_CLIENT_ID --client-secret env.UIPATH_CLIENT_SECRET --tenant "$TENANT"
  env:
    UIPATH_CLIENT_ID: ${{ secrets.UIPATH_CLIENT_ID }}
    UIPATH_CLIENT_SECRET: ${{ secrets.UIPATH_CLIENT_SECRET }}
    TENANT: ${{ vars.UIPATH_TENANT }}

Abgleich von Exitcodes mit dem JSON-Umschlag

Wenn --output json wirksam ist (Standard), enthält der Umschlag dieselben Informationen wie der Exitcode sowie eine visuell lesbare Meldung:

{
  "Result": "ValidationError",
  "Message": "Unknown option '--folder-pth'. Did you mean '--folder-path'?",
  "Instructions": "Run 'uip or folders list --help' to see valid options."
}

Eine Pipeline kann für schnelle Entscheidungen auf $? verzweigen (Wiederholen bei 2, Abbruch bei 3) und den Umschlag für das vollständige Fehlerbild analysieren (Oberfläche Message in einem Slack-Webhook, Ticket Instructions neben dem fehlgeschlagenen Schritt. usw.).

Befehlsspezifische Semantik

Beendigungscodes sind Statuscodes, keine Erfolgscodes. Ein Befehl, der Success mit einer Data -Nutzlast meldet, die „keine Ergebnisse gefunden“ anzeigt, verlässt 0 immer noch. Zum Beispiel gibt uip or folders list --all --name DoesNotExist {"Data": [], …} zurück und beendet 0 – weil die Listenabfrage erfolgreich war; Das Fehlen von Übereinstimmungen ist ein gültiges Ergebnis und kein Fehler.

Wenn ein Befehl „der Vorgang erfolgreich“ von „das Domänenergebnis ist positiv“ unterscheiden muss, steht auf seiner Referenzseite Folgendes:

• uip tm testsets run – Beendet 0immer , sobald der Orchestrator die Testausführungsanforderung akzeptiert und die ExecutionId zurückgibt. Das Bestanden-/Fehlschlag-Ergebnis stammt aus einer separaten uip tm wait + uip tm report get -Kette; Verzweigung für Data.Failed in der Berichtsausgabe. uip tm wait gibt Exitcode 2 bei einer Zeitüberschreitung aus (eine domänenspezifische Wiederverwendung des Authentifizierungsfehlerslots – in uip tm Wait und uip tm executions angegeben).
• uip or jobs start --wait-for-completion – wird beendet als Null, wenn der Auftrag einen Endstatus Faulted oder Stopped erreicht. Ohne --wait-for-completion wird der Befehl 0 beendet, sobald der Orchestrator die Anforderung akzeptiert, unabhängig vom späteren Auftragsergebnis.

Überprüfen Sie die Referenzseite für jeden Befehl, bei dem die Semantik von „success“ nicht eindeutig ist.

Siehe auch

• Globale Optionen – die Flags --output, --output-filter, --log-level, --log-file .
• Skriptingmuster – Wiederholungen, Abrufe, idempotente Pipelines.
• Ausgabeformate – die Umschlagform, die den Exitcode widerspiegelt.
• Versionierung und Stabilität – wie sich der Exit-Code-Vertrag über mehrere Änderungen hinweg entwickelt.