Anleitung: Bereitstellung über CI im Orchestrator

Diese Seite behandelt, was jede CI-Pipeline benötigt, die eine UiPath-Lösung bereitstellt, unabhängig davon, ob Sie auf Azure DevOps, GitHub Actions, Jenkins oder GitLab ausführen: Authentifizierung, Zwischenspeicherung, Vorinstallation von Tools und Versionsheftung. Die plattformspezifische Syntax befindet sich auf den Schemaseiten – diese zeigt Ihnen die schwebenden Teile, sodass Sie jedes davon mit Sicherheit lesen können.

Die Form einer guten CI-Pipeline

Eine Produktionspipeline, die eine Lösung ausgeliefert wird, hat immer die gleichen fünf Phasen:

1. Richten Sie Node.js (Version 18 oder höher) ein.
2. Installieren Sie @uipath/cli in einer angehefteten Version.
3. Installieren Sie die Tools vor, die Sie verwenden werden (damit der erste uip -Aufruf nicht langsamer als der Rest ist).
4. Authentifizieren Sie sich bei einer externen Anwendung mit dem Präfix env. für Geheimnisse.
5. Packen, Veröffentlichen, Bereitstellen – und optional Testen.

Phase 4 ist diejenige, die zwischen den Plattformen am meisten variiert, da die geheime Syntax plattformspezifisch ist. Die Phasen 1–3 und 5 sind überall nahezu identisch.

Authentifizierung: Externe Anwendung + env. Präfix

In einer monitorlosen Umgebung authentifizieren Sie sich mit einer externen Anwendung (Client-Anmeldeinformationen). Unter Authentifizierung – Flow 2 erfahren Sie, wie Sie eine im UiPath Portal erstellen.

Speichern Sie die Anmeldeinformationen im geheimen Speicher Ihrer Plattform ( niemals in Source Control, niemals in einer einfachen envvar-Datei). Übergeben Sie sie mit dem speziellen Präfix env. an uip login :

uip login \
  --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET \
  --tenant "$UIPATH_TENANT"

Das Präfix env.VAR_NAME weist uip an, den Wert aus der Umgebungsvariablen VAR_NAME zur Laufzeit zu lesen. Dadurch wird das Geheimnis aus dem Shell-Verlauf und den Prozessauflistungen herausgehalten – im Gegensatz zu --client-secret "$UIPATH_CLIENT_SECRET", das in der Befehlszeile erweitert wird und über ps gelangen kann.

Warnung:

Verlassen Sie sich nicht auf implizites env-var-Lesen. Wenn Sie nur UIPATH_CLIENT_ID / UIPATH_CLIENT_SECRET ohne das Flag festlegen, werden Sie nicht authentifiziert – diese Funktion wurde vor CLI 1.0 entfernt. Flag immer übergeben; Verwenden Sie env.VAR_NAME wenn der Wert aus der Umgebung aufgelöst werden soll.

Fügen Sie in Ihrer Pipeline die Geheimnisse in die Umgebung des Schritts unter den genauen Variablennamen ein, auf die Sie verweisen:

Plattform	Geheime Syntax in YAML/Gr bereiten	Die Form wird an den Schritt übergeben
GitHub-Aktionen	${{ secrets.UIPATH_CLIENT_ID }} in env:	UIPATH_CLIENT_ID: <value>
Azure DevOps	$(UIPATH_CLIENT_ID) aus einer Variablengruppe in env:	UIPATH_CLIENT_ID: $(UIPATH_CLIENT_ID)
Jenkins	credentialsId: 'UIPATH_CLIENT_ID' hinein withCredentials	exportiert als $UIPATH_CLIENT_ID
GitLab-CI	UIPATH_CLIENT_ID CI/CD-Variable mit Geschützt+Maskiertmarkiert	$UIPATH_CLIENT_ID in script

In jedem Fall sieht der Befehl uip login selbst identisch aus – --client-id env.UIPATH_CLIENT_ID --client-secret env.UIPATH_CLIENT_SECRET. Nur die Art und Weise, wie die Umgebungsvariable im Schritt ankommt, ändert sich.

Sitzungsspeicher

uip login behält die Sitzung in einem .uipath/ -Ordner bei. Bei den meisten CI-Ausführungen ist das Arbeitsverzeichnis bereits zustandslos, sodass die Sitzung mit dem Auftrag endet – was das gewünschte Verhalten ist. Wenn Ihr Runtime persistent ist, entfernen Sie entweder die Sitzung mit uip logout am Ende des Auftrags oder legen Sie --file auf einen lokalen Auftragspfad fest. Siehe Sitzungen und Anmeldeinformationen.

Mehrere Organisationen in einer Pipeline

Eine Sitzung enthält jeweils eine Organisation und einen Mandanten. Um verschiedene UiPath-Organisationen aus derselben Pipeline anzuvisieren – z. B. um eine Lösung von einer Build-Organisation in eine Kundenorganisation zu fördern – führen Sie uip loginzwischen den beiden Blöcken mit einer anderen externen Anwendung erneut aus . Jede Anmeldung überschreibt die vorherige Sitzung.

Erstellen Sie eine externe App pro Organisation (jede mit eigenen OR.* Scopes). Speichern Sie sowohl Client-IDs als auch Geheimnisse im Geheimnisspeicher der Pipeline unter unterschiedlichen Namen:

set -euo pipefail

# --- Organization A ---
uip login \
  --client-id env.ORGA_CLIENT_ID \
  --client-secret env.ORGA_CLIENT_SECRET \
  --tenant Prod

uip or folders list
uip solution pack ./my-solution ./dist --version "$SOLUTION_VERSION"
uip solution publish "./dist/my-solution.$SOLUTION_VERSION.zip"

# --- Organization B — this overwrites the previous session ---
uip login \
  --client-id env.ORGB_CLIENT_ID \
  --client-secret env.ORGB_CLIENT_SECRET \
  --tenant Prod

uip solution publish "./dist/my-solution.$SOLUTION_VERSION.zip"
uip solution deploy run \
  --name "my-solution-$GIT_SHA" \
  --package-name my-solution \
  --package-version "$SOLUTION_VERSION" \
  --folder-name MySolution \
  --folder-path Shared

Dasselbe Muster für verschiedene Mandanten innerhalb einer einzelnen Organisation – mit der Ausnahme, dass Mandanten keine zweite Anmeldung benötigen. Übergeben Sie --tenant <name> bei einem beliebigen uip or … -Aufruf, um den Sitzungsmandanten für einen einzelnen Befehl ohne erneute Authentifizierung zu überschreiben.

Hinweis:

Dies ist ein serielles Muster. Jede uip login überschreibt die gespeicherte Sitzung, sodass zu jedem Zeitpunkt nur eine Organisation erreichbar ist. Wenn Sie Befehle für zwei Organisationen gleichzeitig ausführen müssen (z. B. parallele Matrixaufträge), geben Sie jedem Auftrag einen eigenen Runtime oder einen eigenen --file / HOME Scope – siehe Sitzungen und Anmeldeinformationen.

Installieren Sie Tools vor, um die Buildzeiten deterministisch zu halten

Die CLI wird ohne vorinstallierte Tools ausgeliefert. Wenn Sie zum ersten Mal ein Verb von einem deinstallierten Tool ausführen, installiert uip es automatisch von npm – was auf einem Laptop in Ordnung ist, aber dem ersten Befehl auf einem zustandslosen CI-Ausführungsmodell eine Latenz von 5–10 Sekunden hinzufügt.

Installieren Sie die Tools, die Sie vorab verwenden, als separater Schritt:

uip tools install @uipath/orchestrator-tool @uipath/solution-tool

Fügen Sie @uipath/test-manager-tool hinzu, wenn Sie den Test Manager ausführen, @uipath/agent-tool , wenn Sie Agents bereitstellen, @uipath/resource-tool wenn Sie Assets/Warteschlangen/Buckets außerhalb einer Lösung verwalten. Die vollständige Liste finden Sie in der Toolreferenz .

Die automatische Installation ist ein No-Op, wenn das Tool bereits installiert ist, sodass der Vorinstallationsschritt die einzige Verhaltensänderung ist, die Sie benötigen – nichts anderes in Ihrer Pipeline muss davon wissen.

Hinweis:

CI=true deaktiviert die automatische Installation nicht . Es gibt keinen env-var-Schalter; Die Vorinstallation ist die einzige Möglichkeit, dies zu vermeiden. Siehe Installieren der UiPath CLI – Steuern des automatischen Installationstools.

Zwischenspeichern Sie das globale npm-Verzeichnis

CI-Ausführungen, die @uipath/cli bei jedem Auftrag neu installieren, verlieren 20 bis 40 Sekunden für Download und Dekomprimierung. Durch das Zwischenspeichern des globalen node_modules -Verzeichnisses von npm wird dies zu einem Cache-Erfolg – normalerweise in einer Sekunde.

Das zwischenzuspeicherende Verzeichnis ist das von npm root -g gemeldete Verzeichnis (normalerweise ~/.npm-global/lib/node_modules unter Linux/macOS, %APPDATA%\npm\node_modules unter Windows). Schlüsseln Sie den Cache auf der CLI-Version, die Sie anheften, damit eine Versionserhöhung den Cache sauber ungültig macht:

Plattform	Cache-Mechanismus
GitHub-Aktionen	actions/cache mit path: ~/.npm-global/lib/node_modules und key: uip-${{ version }}-${{ runner.os }}
Azure DevOps	Cache@2 Schlüssel für die Versionsvariable
Jenkins	Das Plugin „Auftragscache“ oder ein manuell verwalteter Arbeitsbereichsordner
GitLab-CI	cache: Block der obersten Ebene mit key: uip-$CLI_VERSION

Wenn der Cache eintrifft, können Sie sowohl npm install -g @uipath/cli als auch uip tools install überspringen – die ausführbare Datei uip und ihre Tools befinden sich bereits auf PATH. Ein kleiner Bash Guard macht dies sauber:

if ! command -v uip >/dev/null; then
  npm install -g "@uipath/cli@${CLI_VERSION}"
  uip tools install @uipath/orchestrator-tool @uipath/solution-tool
fi

Das konkrete YAML/Grooty für jede Plattform befindet sich auf den Rechnungsseiten.

Versionen für Reproduzierbarkeit anheften

Reproduzierbare Pipelines anheften. Vier Versionen sind wichtig:

• Node.js – den Hauptteil anheften (20.x unter setup-node von GitHub Actions, versionSpec: '20.x' in Azure DevOps).
• @uipath/cli – genau anheften (@1.0.0), kein Bereich.
• Tools – optional. Standardmäßig verfolgen sie die Zeile MaJOR.MINOR der CLI nach; nur anheften, wenn Sie eine strenge Reproduzierbarkeit auf Patch-Ebene benötigen (@uipath/solution-tool@1.0.2).
• Die Version Ihrer eigenen Lösung – übergeben Sie --version explizit an uip solution pack . Verlassen Sie sich niemals auf den Standard 1.0.0 in CI.

# Pin these once at the top of the pipeline; reuse below
CLI_VERSION="1.0.0"
SOLUTION_VERSION="1.2.0-ci.${BUILD_NUMBER}"

npm install -g "@uipath/cli@${CLI_VERSION}"
uip tools install @uipath/solution-tool @uipath/orchestrator-tool

uip solution pack ./my-solution ./dist --version "$SOLUTION_VERSION"

Der .zip -Pfad ist deterministisch (./dist/my-solution.${SOLUTION_VERSION}.zip), sodass nachgelagerte Schritte ihn erstellen können, ohne die uip solution pack -JSON-Ausgabe zu analysieren.

Weitere Informationen zu den Regeln zum Anheften von Tools finden Sie unter Skriptingmuster – Anheften von Versionen in CI .

Der minimale Bereitstellungsblock

Jede Plattform läuft darauf hinaus:

set -euo pipefail

# Authenticate
uip login \
  --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET \
  --tenant "$UIPATH_TENANT"

# Pack
uip solution pack ./my-solution ./dist \
  --name my-solution \
  --version "$SOLUTION_VERSION"

# Publish
uip solution publish "./dist/my-solution.${SOLUTION_VERSION}.zip"

# Deploy
uip solution deploy run \
  --name "my-solution-${ENVIRONMENT}" \
  --package-name my-solution \
  --package-version "$SOLUTION_VERSION" \
  --folder-name MySolution \
  --folder-path Shared

set -euo pipefail führt dazu, dass das Skript schnell fehlschlägt: -e bricht bei jedem Exit ungleich Null ab, -u erfasst nicht definierte Variablen, -o pipefail überträgt Fehler über Pipes. Dies ist das Muster, das jedes Menü in dieser Dokumentation verwendet. Siehe Skriptmuster – Strikte Shell-Optionen.

Optional: Tests nach der Bereitstellung durchführen

Wenn die Lösung einen Testsatz enthält, starten → warten → überprüfen, bevor die Pipeline grün markiert wird. Das Drei-Schritt-Muster ist wichtig: uip tm testsets run beendet 0 , sobald die Ausführung in die Warteschlange gestellt wird, nicht wenn die Tests erfolgreich sind – also benötigen Sie uip tm wait zum Blockieren und uip tm report get zum Lesen des Ergebnisses.

Das vollständige Muster mit Fehlerbehandlung finden Sie unter Anleitung: Ausführen von Tests über die CLI .

Die erneute Authentifizierung mitten in der Pipeline wird behandelt

Zugriffstoken können während Pipelines mit langer Ausführungszeit ablaufen. Die Seite „scripting-patterns“ hat das kanonische Wiederholungsmuster: Verzweigen bei Exitcode 2 (AuthenticationError), uip login erneut ausführen, einmal wiederholen, andernfalls fehlschlagen. In den meisten CI-Pipelines ist dies unnötig – Aufträge sind kurz genug, dass das Token der ersten Anmeldung die gesamte Ausführung dauert – aber lange Testsuiten oder Schleifen mit mehreren Mandanten können davon profitieren.

Plattformkonzepte

Für vollständige, kopier- und einfügbare Pipelines in der nativen Syntax Ihrer Plattform:

• CI/CD-Release: Azure DevOps
• CI/CD-Real: GitHub Actions
• CI/CD-Referenz: Jenkins
• CI/CD-Rezept: GitLab CI

Jedes Konzept zeigt die vollständige Pipeline (Install → Authentifizierung → Packen → Veröffentlichen → Bereitstellen → Test), die geheime Verzweigung, einen Cache-Eintrag und Variationen zum Anheften von Versionen und Ausführen von Tests.

Siehe auch

• Ihre erste Pipeline – der minimale Flow mit drei Befehlen.
• So: Packen und Veröffentlichen einer Lösung – Versionsdiskretion, Förderung für mehrere Umgebungen, Rollback.
• Authentifizierung – die drei Flows und wann sie jeweils verwendet werden sollen.
• Skriptingmuster – Exitcodes, Wiederholung, JSON-Filterung.
• Installieren von UiPath CLI – CI/CD – Vorinstallation und Caching.