Procédure: déployer dans Orchestrator depuis CI

Cette page couvre les besoins de chaque pipeline CI déployé dans une solution UiPath, que ce soit sur Azure DevOps, GitHub Actions, Jenkins ou GitLab: authentification, mise en cache, préinstallation de l'outil et épinglage de la version. La syntaxe spécifique à la plate-forme se trouve dans les pages de licence . Celle-ci vous donne les parties mobiles afin que vous puissiez les lire en toute confiance.

La forme d’un bon pipeline CI

Un pipeline de production qui fournit une solution comporte toujours les mêmes étapes:

1. Configurez Node.js (version 18 ou ultérieure).
2. Installez @uipath/cli dans une version épinglée.
3. Préinstallez les outils que vous utiliserez (afin que le premier appel uip ne soit pas plus lent que le reste).
4. Authentifiez-vous avec une application externe en utilisant le préfixe env. pour les secrets.
5. Créer le package, publier, déployer et tester éventuellement.

L’étape 4 est celle qui varie le plus entre les plateformes, car la syntaxe secrète est spécifique à la plateforme. Les étapes 1 à 3 et 5 sont presque identiques dans toutes les étapes.

Authentification: Application externe + env. préfixe

Dans un environnement sans affichage, vous vous authentifiez avec une application externe (informations d’identification du client). Voir Authentification — Flux 2 pour savoir comment en créer une dans le portail UiPath.

Stockez les informations d'identification dans le magasin secret de votre plate-forme ( jamais dans le contrôle de code source, jamais dans un fichier var d'environnement simple). Transmettez-les à uip login avec le préfixe spécial env. :

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

Le préfixe env.VAR_NAME indique à uip de lire la valeur à partir de la variable d'environnement VAR_NAME au moment du runtime. Cela maintient le secret en dehors de l’historique et des listes de processus, contrairement à --client-secret "$UIPATH_CLIENT_SECRET", qui se développe sur la ligne de commande et peut fuiter via ps.

Avertissement :

Ne reposez pas sur la lecture implicite env-var. Le fait de configurer UIPATH_CLIENT_ID / UIPATH_CLIENT_SECRET seul, sans l’indicateur, ne vous authentifiera pas — cette fonctionnalité a été supprimée avant la version CLI 1.0. Transmettez toujours l'indicateur; utilisez env.VAR_NAME lorsque vous souhaitez que la valeur soit résolue à partir de l'environnement.

Dans votre pipeline, injectez les secrets dans l'environnement de l'étape sous les noms de variables exacts que vous référencez:

Plate-forme	Syntaxe secrète dans YAML/Ga uniquement	forme transmise à l'étape
Actions de GitHub	${{ secrets.UIPATH_CLIENT_ID }} dans env:	UIPATH_CLIENT_ID: <value>
Azure DevOps	$(UIPATH_CLIENT_ID) à partir d'un groupe de variables dans env:	UIPATH_CLIENT_ID: $(UIPATH_CLIENT_ID)
Jenkins	credentialsId: 'UIPATH_CLIENT_ID' À l'intérieur withCredentials	Exporté en tant que $UIPATH_CLIENT_ID
CI GitLab	UIPATH_CLIENT_ID Variable CI/CD, marquée Proté+Masqué	$UIPATH_CLIENT_ID dans script

Dans tous les cas, la commande uip login elle-même est identique — --client-id env.UIPATH_CLIENT_ID --client-secret env.UIPATH_CLIENT_SECRET Seule la façon dont la variable d'environnement arrive dans l'étape change.

Stockage de la session

uip login persiste la session dans un dossier .uipath/ . Sur la plupart des exécuteurs CI, le répertoire de travail est déjà sans état, de sorte que la session se termine par la tâche, qui est le comportement souhaité. Si votre exécuteur est persistant, supprimez la session avec uip logout à la fin de la tâche ou définissez --file sur un chemin local de tâche. Voir Sessions et informations d’identification.

Plusieurs organisations dans un même pipeline

Une session contient une organisation et un locataire à la fois. Pour cibler différentes organisations UiPath à partir du même pipeline, par exemple pour promouvoir une solution depuis une organisation de développement dans une organisation cliente, réexécutez uip login entre les deux blocs avec une application externe différente. Chaque connexion écrase la session précédente.

Créez une application externe par organisation (chacune avec ses propres étendues OR.* ). Stockez les ID client et les clés secrètes dans le magasin secret du pipeline sous des noms distincts:

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

Même modèle pour différents locataires au sein d'une même organisation, sauf que les locataires n'ont pas besoin d'une deuxième connexion. Transmettez --tenant <name> sur n’importe quel appel uip or … pour remplacer le locataire de session pour une seule commande, sans réauthentifier.

Remarque :

Il s'agit d'un modèle de série . Chaque uip login écrase la session stockée, de sorte qu’une seule organisation est accessible à tout moment. Si vous devez exécuter des commandes sur deux organisations simultanément (par exemple, des tâches à matrice parallèle), donnez à chaque tâche son propre exécuteur ou sa propre étendue --file / HOME — voir Sessions et informations d'identification.

Préinstaller des outils pour garder les temps de développement déterministes

La CLI est livrée sans outil préinstallé. La première fois que vous exécutez un verbe à partir d'un outil désinstallé, uip l'installe automatiquement à partir de npm - ce qui convient sur un ordinateur portable, mais ajoute 5 à 10 secondes de latence à la première commande sur un exécuteur CI sans état.

Installez les outils que vous utilisez dès le départ, dans le cadre d’une étape distincte:

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

Ajoutez @uipath/test-manager-tool lorsque vous exécutez Test Manager, @uipath/agent-tool lorsque vous déployez des Agents, @uipath/resource-tool lorsque vous gérez des ressources/files d’attente/compartiments en dehors d’une solution. Consultez la référence des outils pour obtenir la liste complète.

L'installation automatique n'est pas prise en charge lorsque l'outil est déjà installé, de sorte que l'étape de pré-installation est le seul changement de comportement dont vous avez besoin - rien d'autre dans votre pipeline ne doit le savoir.

Remarque :

CI=true ne désactive pas l'installation automatique. Il n’y a pas de commutateur env-var; pré-installer est le seul moyen d'éviter cela. Voir Installation de la UiPath CLI — Contrôle de l'installation automatique de l'outil.

Mettre en cache le répertoire global npm

Les exécuteurs CI qui réinstallent @uipath/cli sur chaque tâche perdent 20 à 40 secondes de téléchargement et de décompression. La mise en cache du répertoire npm global node_modules le transforme en un résultat de cache, généralement inférieur à une seconde.

Le répertoire à mettre en cache est celui indiqué par npm root -g (généralement ~/.npm-global/lib/node_modules sous Linux/macOS, %APPDATA%\npm\node_modules sous Windows). Clé le cache sur la version CLI que vous épinglez, de sorte qu'une bogue de version invalide correctement le cache:

Plate-forme	Mécanisme de cache
Actions de GitHub	actions/cache avec path: ~/.npm-global/lib/node_modules et key: uip-${{ version }}-${{ runner.os }}
Azure DevOps	Cache@2 clé sur la variable de version
Jenkins	Le plug-in Job Cacher ou un dossier d’espace de travail géré manuellement
CI GitLab	Bloc cache: de niveau supérieur avec key: uip-$CLI_VERSION

Lorsque le cache atteint, vous pouvez ignorer à la fois npm install -g @uipath/cli et uip tools install — l'exécutable uip et ses outils sont déjà sur le PATH Un petit garde-fou bash le fait proprement:

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

Le dossier YAML/Gro package pour chaque plate-forme se trouve dans les pages de instructions.

Épingler les versions à des fins de reproductibilité

Les pipelines reproductibles épinglent tout. Quatre versions comptent:

• Node.js — épingler le principal (20.x sur setup-node des Actions GitHub, versionSpec: '20.x' sur Azure DevOps).
• @uipath/cli — épingler exactement (@1.0.0), pas une plage.
• Outils — facultatif. Par défaut, ils suivent la ligne MAJOR.MINIOR de la CLI; épingler uniquement si vous avez besoin d'une reproductibilité stricte au niveau du correctif (@uipath/solution-tool@1.0.2).
• Version de votre propre solution — transmettez --version à uip solution pack explicitement. Ne vous fondez jamais sur la valeur 1.0.0 par défaut dans 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"

Le chemin .zip est déterministe (./dist/my-solution.${SOLUTION_VERSION}.zip), les étapes en aval peuvent donc le construire sans analyser la sortie JSON uip solution pack .

Voir Modèles de script — épinglage des versions dans CI pour les règles d'épinglage des outils en détail.

Bloc de déploiement minimal

Chaque plate-forme se résume à ceci:

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 rend le script échoué rapidement: -e abandonne toute sortie non nulle, -u capture les variables indéfinies, -o pipefail propage les échecs via les canaux. Il s'agit du modèle utilisé par chaque formule dans cette documentation. Voir Modèles de script — Options shell strictes.

Facultatif: exécuter des tests après le déploiement

Si la solution comprend un ensemble de tests, lancez → attendez → vérifiez-le avant de marquer le pipeline en vert. Le modèle en trois étapes est important: uip tm testsets run quitte 0 dès que l’exécution est mise en file d’ attente, et non lorsque les tests réussissent. Vous avez donc besoin de uip tm wait pour bloquer et uip tm report get pour lire le verbe.

Consultez la section Comment procéder: exécuter des tests à partir de la CLI pour obtenir le modèle complet avec la gestion des erreurs.

Gérer le pipeline de réauthentification à mi-parcours

Les jetons d'accès peuvent expirer pendant les pipelines de longue durée. La page scripting-patterns suit le modèle de réessai canonique: branche sur le code de sortie 2 (AuthenticationError), réexécutez uip login, réessayez une fois, échouez dans le cas contraire. Dans la plupart des pipelines CI, cela est inutile — les tâches sont suffisamment courtes pour que le jeton de la connexion initiale dure toute l'exécution — mais les suites de tests longues ou les boucles de promotion multi-locataires peuvent en bénéficier.

Revenus de la plate-forme

Pour des pipelines complets et modifiables dans la syntaxe native de votre plate-forme:

• Licence CI/CD: Azure DevOps
• Formule CI/CD: GitHub Actions
• Formule CI/CD : Jenkins
• Schéma CI/CD: GitLab CI

Chaque règle affiche le pipeline complet (installer → authentifier → publier → déployer → test), la connexion secrète, une entrée de cache et les variations pour épingler les versions et les tests en cours d'exécution.

Voir également

• Votre premier pipeline — le flux minimum de trois commandes.
• Comment procéder: compresser et publier une solution — Distinction des versions, promotion multi-environnements, restauration.
• Authentification — les trois flux et quand les utiliser.
• Modèles de script — codes de sortie, réessai, filtrage JSON.
• Installation de la UiPath CLI — CI/CD — détails de préinstallation et de mise en cache.