J'ai recu cette email, et je ne comprend rien, peux tu me dire en quoi consiste l'action et

surtout pourquoi?? Hello Karim, Jean-Christophe, Pour information, nous venons de finir une
réunion avec Paulo et Philippe où nous avons échangé autour du besoin concernant le CLI
WINDOWS 2022, deux actions seront menées de leur côté : Création d’une external
application pour la récupération des dépendances avec le cli, avec un accès limité à un
scope, comme le soulignait le mail de Matheus : « Si toutes les dependances nécessaires
sont dans le feed de l'Orchestrator, utiliser plutôt les paramètres
libraryOrchestratorApplicationId, libraryOrchestratorApplicationSecret et
libraryOrchestratorApplicationScope (external application authentication). Pour cela, il faut
qu'un admin sur l'Orchestrator crée une external application avec les application scopes
nécessaires (le scope [Link] devrait être suffisant) et qu'il te fournisse le client id et
client secret. »
[Link]
cations Installation sur la bis30 de la version nécessaire de .NET (6.0.7) afin que le CLI
puisse fonctionner sur la PIC :
[Link]
unning-uipathcliwindows Cela permettra de poursuivre mes actions, Bonne journée,
Raisonnement terminé pendant 24 secondes

Voici un résumé détaillé des deux actions mentionnées dans l'email, avec des explications
sur leur utilité :

●​ Création d’une external application pour le CLI

○​ But de l'action :
■​ Permettre au CLI Windows 2022 d'accéder aux dépendances
nécessaires en s'authentifiant auprès de l'Orchestrator.
○​ Comment ça fonctionne :
■​ Un administrateur de l'Orchestrator doit créer une "external
application" avec un accès limité via un scope spécifique (par
exemple, le scope [Link]).
■​ L'application utilise des paramètres d'authentification
(libraryOrchestratorApplicationId,
libraryOrchestratorApplicationSecret,
libraryOrchestratorApplicationScope) pour sécuriser l'accès au feed
des dépendances.
■​ Ces identifiants (client id et client secret) seront ensuite fournis pour
que le CLI puisse se connecter et récupérer les dépendances.
○​ Pourquoi c'est nécessaire :
■​ Cela garantit que le CLI n'accède qu'aux ressources nécessaires, en
limitant les permissions pour des raisons de sécurité.
■​ C'est la méthode recommandée lorsqu'on dispose de toutes les
dépendances dans le feed de l'Orchestrator, comme expliqué dans le
mail de Matheus et la documentation officielle UiPath.
■​ Documentation UiPath sur la gestion des external applications
●​ Installation de .NET 6.0.7 sur la machine bis30
○​ But de l'action :
■​ Assurer que le CLI puisse fonctionner correctement sur la plateforme
PIC.
 ○​ Comment ça fonctionne :
■​ Installer la version .NET 6.0.7 sur la machine désignée (bis30) pour
répondre aux exigences du CLI.
■​ Cette installation permet au CLI Windows 2022 de s'exécuter en
utilisant la bonne version du runtime .NET.
■​ Documentation UiPath sur l'exécution des tâches avec le CLI
○​ Pourquoi c'est nécessaire :
■​ Le CLI dépend de .NET 6.0.7 pour fonctionner correctement ; sans
cette version, des erreurs d'exécution ou d'incompatibilité pourraient
survenir.
■​ Cela permet de garantir une intégration fluide avec l'infrastructure
existante et d'éviter des dysfonctionnements lors de l'exécution des
tâches.

En résumé :​
Ces deux actions préparent l'environnement pour que le CLI Windows 2022 puisse
récupérer ses dépendances de manière sécurisée et fonctionner correctement sur le serveur
ciblé. La création de l'external application assure un accès restreint et contrôlé, tandis que
l'installation de .NET 6.0.7 garantit la compatibilité technique du CLI sur la machine PIC.
Cela permet à l'expéditeur de poursuivre ses actions en s'appuyant sur une infrastructure
stable et sécurisée.

o3-mini-high

Vous avez dit :

À propos des pipelines CI_CD.pdf
PDF
CI_CD Pipelines for UiPath Process Deployment Series_ GitHub [Link]
PDF
UiPath-DevOps-Scripts (1).pdf
PDF
[Link]
PDF
peux tu me dire qu'est ce que cli et a quoi cela sert?
Raisonnement terminé pendant 16 secondes

●​ Définition générale
○​ La CLI (Command-Line Interface ou interface en ligne de commande) est un
outil qui permet d’interagir avec un logiciel via des commandes textuelles,
plutôt qu’avec une interface graphique.
○​ Elle est particulièrement utile pour automatiser des tâches répétitives et
intégrer des opérations dans des scripts ou des pipelines CI/CD.
○​
●​ Utilisation dans l’écosystème UiPath
○​ Automatisation des tâches :
■​ La CLI UiPath permet d'exécuter des opérations telles que l’emballage
de projets Studio en packages NuGet, le déploiement de ces
 packages sur Orchestrator, l’exécution de tests, ou le lancement de
jobs.
■​ Cela facilite l’intégration de ces tâches dans des workflows
automatisés, notamment dans des pipelines CI/CD.
■​
○​ Intégration avec des outils tiers :
■​ La CLI est conçue pour fonctionner sans plug-in spécifique, ce qui
permet de l’intégrer facilement à des outils comme GitLab, Jenkins,
Azure DevOps, etc.
■​ Elle contribue à automatiser la chaîne de livraison continue en
déclenchant, par exemple, le packaging et le déploiement dès qu’une
modification de code est détectée.
●​ Exemples pratiques
○​ Packaging d’un projet : Utiliser la CLI pour convertir un projet Studio en
package NuGet, étape essentielle pour le déploiement.
○​ Déploiement automatisé : Intégrer la CLI dans un pipeline pour déployer
automatiquement le package sur Orchestrator, permettant ainsi une livraison
continue.
○​ Exécution de tests : Lancer des tests de validation directement depuis la
ligne de commande pour s’assurer que le package est conforme avant sa
mise en production.
○​
●​ Points techniques à noter
○​ Versions et plateformes :
■​ Il existe différentes versions de la CLI pour Windows et Linux (par
exemple, [Link] pour Windows), chacune adaptée aux
spécificités des environnements d’exécution.
○​ Prérequis :
■​ La CLI nécessite parfois des prérequis techniques, comme
l’installation d’une version spécifique de .NET (exemple : .NET 6.0.7),
afin d’assurer son bon fonctionnement.
○​

En résumé, la CLI est un outil indispensable pour automatiser et intégrer des tâches de
gestion, de déploiement et de test dans l’écosystème UiPath, ce qui permet de gagner en
efficacité et en fiabilité dans le cycle de développement et de déploiement des
automatisations.

o3-mini-high

Vous avez dit :

donc sur l'orchestrator uipath version 2022, si on dispose d'un pipeline CI/CD pour deploye
rles packages nuget sur l'orchestrator, il faudra donc inserer le cli uipath? De plus sachant
que les packages s'achemine via bitbucket, jenkins, Xlrelease , XlDeploy, ou faut in
positionne rla CLI uipath?
Raisonnement terminé pendant 20 secondes

●​ Utilisation de la CLI dans un pipeline CI/CD

 ○​ Oui, pour automatiser le packaging, le déploiement et l’exécution de tests sur
Orchestrator, il est recommandé d’intégrer la CLI UiPath dans votre pipeline.
○​ La CLI vous permet d’exécuter des commandes en ligne de commande pour
transformer vos projets Studio en packages NuGet, déployer ces packages et
lancer des tests, le tout sans intervention manuelle.
○​
●​ Positionnement de la CLI dans votre chaîne CI/CD
○​ Sur l’agent de build/déploiement :
■​ La CLI doit être installée (ou téléchargée dynamiquement) sur l’agent
qui exécute vos scripts de déploiement.
■​ Cet agent est souvent celui qui héberge vos jobs Jenkins, XL
Release, ou XL Deploy.
○​ Intégration dans le pipeline :
■​ Vous ajoutez une étape dans votre pipeline (géré via Bitbucket,
Jenkins, etc.) qui appelle les commandes de la CLI pour pousser le
package NuGet vers l’Orchestrator.
■​ La CLI n’est pas installée sur l’Orchestrator lui-même, mais sur la
machine ou l’agent orchestrant le déploiement.
○​ Prérequis techniques :
■​ Assurez-vous que l’agent dispose des prérequis, notamment la
version requise de .NET (par exemple, .NET 6.0.7 pour
[Link]).
○​
●​ Cas pratique dans votre environnement
○​ Si vos packages s’acheminent depuis Bitbucket et que Jenkins, XL Release
et XL Deploy orchestrent les différentes étapes, vous pouvez intégrer la CLI
dans une étape dédiée de votre pipeline pour :
■​ Construire et packager le projet.
■​ Déployer le package NuGet sur Orchestrator.
■​ Lancer des tests automatisés sur Orchestrator après le déploiement.
○​ Cette intégration centralisée sur l’agent de déploiement permet une gestion
fluide et automatisée du cycle de vie de vos packages.

En résumé, dans votre pipeline CI/CD pour UiPath Orchestrator 2022, la CLI UiPath joue un
rôle clé et doit être positionnée sur l’agent qui exécute les étapes de déploiement, afin
d’automatiser efficacement la gestion des packages NuGet.

o3-mini-high

Vous avez dit :

ou recuperere t on la CLI uipath?
Raisonnement terminé pendant 21 secondes

●​ Téléchargement depuis le flux officiel

○​ Vous pouvez récupérer la CLI UiPath en la téléchargeant depuis le flux public
officiel UiPath, accessible via Visual Studio Artifacts à l’adresse suivante :​
[Link]
 ○​ Une fois sur le flux, utilisez la barre de recherche pour taper « [Link] » et
sélectionnez la version souhaitée (par exemple, pour Windows, la version
[Link]).
○​
●​ Documentation officielle
○​ La documentation officielle de UiPath fournit des instructions détaillées pour
le téléchargement et l’installation de la CLI. Vous pouvez la consulter ici :​
[Link]
about-uipath-cli
○​ Cette documentation explique notamment comment extraire le package
téléchargé pour accéder à l’exécutable ([Link] pour Windows).
●​ Intégration dans votre pipeline CI/CD
○​ La CLI doit être installée sur l’agent de build/déploiement (Jenkins, XL
Release, etc.), et non sur l’Orchestrator lui-même.
○​ Une fois en place, elle peut être invoquée par des scripts pour automatiser le
packaging, le déploiement et l’exécution de tests sur Orchestrator.

o3-mini-high

Vous avez dit :

et si on ne veut pas integreer la CLI Uipath, commbt doit on alors faire
Raisonnement terminé pendant 23 secondes

●​ Utilisation directe des API d’Orchestrator

○​ Vous pouvez concevoir des scripts personnalisés (en PowerShell, Python,
etc.) qui font appel directement aux API REST d’Orchestrator pour :
■​ Publier et déployer vos packages NuGet.
■​ Lancer des jobs ou exécuter des tests.
○​ Cette approche offre une flexibilité totale mais nécessite une gestion
manuelle des authentifications et des appels API.
●​ Exploitation des plugins ou extensions CI/CD existants
○​ Certains outils comme Jenkins, XL Release ou XL Deploy disposent de
plugins natifs ou d’intégrations spécifiques pour UiPath, permettant de
déployer des packages sans passer par la CLI.
○​ Ces solutions simplifient le processus en encapsulant les interactions avec
Orchestrator.
●​ Utilisation de scripts DevOps tiers
○​ Des bibliothèques comme les UiPath-DevOps-Scripts (disponibles sur
GitHub) offrent des fonctions similaires à celles de la CLI en interfaçant
directement avec Orchestrator.
○​ Vous pouvez intégrer ces scripts dans votre pipeline pour gérer le packaging,
le déploiement et l’exécution de tests.
●​ Considérations pratiques
○​ Sans la CLI, vous devrez probablement développer des solutions sur mesure
pour gérer les erreurs, les mises à jour de version et la sécurité des échanges
avec Orchestrator.
○​ Assurez-vous que votre solution alternative s’intègre bien avec l’ensemble de
votre chaîne CI/CD (Bitbucket, Jenkins, XL Release, XL Deploy).
En résumé, si vous ne souhaitez pas intégrer la CLI UiPath, vous pouvez opter pour des
appels directs aux API d’Orchestrator, utiliser des plugins CI/CD spécifiques ou exploiter des
scripts DevOps tiers pour automatiser le déploiement de vos packages NuGet.

o3-mini-high

Vous avez dit :

donne moi le lien exacte pour telecharger la cli
Raisonner sur le téléchargement de la CLI UiPath pendant 19 secondes

●​ Lien de téléchargement pour la CLI UiPath Windows

○​ Vous pouvez télécharger la version 23.10.8753.32995 de la CLI UiPath pour
Windows en utilisant le lien suivant :​
[Link]
Get/[Link]/versions/23.10.8753.32995
○​ Cette version est directement disponible sur le flux public officiel de UiPath.
○​
●​ Pour consulter d’autres versions ou la version multiplateforme
○​ Rendez-vous sur le flux général à l’adresse :​
[Link]
○​ Vous pourrez ainsi choisir la version qui correspond à vos besoins ou
télécharger la version pour Linux ([Link]).
●​ Documentation associée
○​ Pour plus d’informations sur l’installation et l’utilisation de la CLI UiPath,
consultez la documentation officielle :​
[Link]
about-uipath-cli

Ces ressources vous permettront d’intégrer la CLI dans votre pipeline CI/CD ou de l’utiliser
selon vos besoins.

o3-mini-high

Vous avez dit :

mais que contient ce cli, il n'y a pas une note detaillé??
Raisonné sur le contenu de la CLI UiPath pendant 24 secondes

●​ Contenu de la CLI UiPath

○​ Ensemble de commandes dédiées à l'automatisation
■​ Permet de convertir les projets UiPath Studio en packages NuGet
(packaging).
■​ Facilite le déploiement de ces packages sur Orchestrator via des
commandes automatisées.
■​ Intègre des fonctionnalités pour exécuter des tests automatisés et
déclencher des jobs sur Orchestrator.
■​ Propose des options pour gérer le versioning automatique lors des
mises à jour de packages.
■​ Dispose d'une commande pour signer les packages (la signature n'est
pas intégrée par défaut lors du packaging).
 ■​ Se décline en deux versions :
■​ [Link] pour les environnements Windows.
■​ [Link] pour les environnements Linux.
○​ Spécificités techniques
■​ Ne supporte pas l'authentification unique (SSO) ni les déclencheurs
locaux.
■​ Fonctionne en s'appuyant sur des prérequis techniques, notamment
une version spécifique de .NET (par exemple, .NET 6.0.7 pour la
version Windows).
○​ Documentation détaillée
■​ Pour une description complète et des exemples d'utilisation, la
documentation officielle de UiPath est disponible ici :​
[Link]
-guide/about-uipath-cli
■​ Cette documentation offre une note détaillée sur l'ensemble des
commandes, leurs paramètres et les cas d'usage typiques.
○​

o3-mini-high

Vous avez dit :

il ne faut pas un module powershell speciale???
Raisonner sur la nécessité d'un module PowerShell spécial pendant 18 secondes

●​ La CLI UiPath est autonome

○​ Il n'est pas nécessaire d'installer un module PowerShell spécifique pour
utiliser la CLI.
○​ La CLI se présente sous la forme d'un exécutable ([Link] pour Windows)
extrait du package NuGet, que vous pouvez appeler directement depuis
PowerShell.
●​ Utilisation depuis PowerShell
○​ Vous pouvez lancer la CLI dans vos scripts PowerShell en exécutant
l'exécutable et en passant les paramètres requis.
○​ Par exemple, vous pouvez écrire une commande comme :
■​ .\[Link] pack --project "chemin\vers\projet" --output
"chemin\vers\output"
○​ Cela permet d'intégrer directement la CLI dans vos pipelines CI/CD sans
étape supplémentaire d'importation d'un module.
●​ Option des scripts DevOps
○​ Bien que non indispensable, UiPath propose également une série de scripts
PowerShell (les UiPath-DevOps-Scripts) disponibles sur GitHub.
○​ Ces scripts encapsulent les commandes de la CLI pour simplifier des
opérations comme le packaging, le déploiement et l'exécution de tests.
○​ Ils peuvent être une alternative si vous préférez une approche scriptée plus
complète dans votre chaîne CI/CD.

En résumé, vous n'avez pas besoin d'un module PowerShell spécial pour utiliser la CLI
UiPath, celle-ci pouvant être directement appelée depuis vos scripts PowerShell.
Cependant, l'utilisation des scripts DevOps est une option intéressante pour automatiser et
simplifier vos tâches.

o3-mini-high

Vous avez dit :

[Link] et cela c'est quoi???
Raisonner sur le dépôt GitHub de UiPath CLI pendant 18 secondes

●​ Repository officiel
○​ Ce lien pointe vers le dépôt GitHub officiel de la CLI UiPath, géré par UiPath.
○​ Il contient le code source, la documentation, et les instructions relatives à la
construction et à l’utilisation de la CLI.
●​ But et utilité
○​ Le dépôt permet aux développeurs de consulter comment la CLI est
implémentée, de suivre ses évolutions, et même de contribuer ou de
personnaliser l’outil si besoin.
○​ Il sert également de référence pour comprendre l’architecture et les
fonctionnalités offertes par la CLI, notamment pour le packaging, le
déploiement et l’exécution de tests dans un environnement CI/CD.
●​ Complément avec le package NuGet
○​ Bien que vous puissiez télécharger la CLI sous forme binaire via le flux
NuGet (comme indiqué précédemment), ce dépôt GitHub offre une vue
détaillée sur le fonctionnement interne et le développement continu de l’outil.

o3-mini-high

Vous avez dit :

si on revient a la cli, installer sur Jenkins, elle permet quoi?? precisement?
Raisonné sur l'installation de la CLI UiPath sur Jenkins pendant 14 secondes

●​ Automatisation complète du cycle de vie

○​ Packaging : La CLI permet de convertir un projet UiPath Studio en un
package NuGet via une commande comme « pack ». Cela automatise la
phase de construction du package.
○​ Déploiement : Elle déploie automatiquement ce package sur UiPath
Orchestrator avec des commandes dédiées (ex. « deploy »), ce qui élimine le
besoin de déploiement manuel.
○​ Exécution de tests et jobs : Vous pouvez lancer des tests automatisés et
déclencher des jobs sur Orchestrator pour valider et exécuter vos
automatisations.
○​ Gestion de version : La CLI peut gérer automatiquement le versioning, en
incrémentant les numéros de version lors de chaque déploiement.
●​ Intégration dans Jenkins
○​ Déclenchement par pipeline : Dans un environnement Jenkins, la CLI est
installée sur l’agent de build/de déploiement. Lorsque Jenkins détecte une
nouvelle commit (par exemple via Bitbucket), il peut exécuter une série
d’étapes qui appellent la CLI.
 ○​ Workflow automatisé : Le pipeline peut inclure des étapes pour packager le
projet, déployer le package sur Orchestrator, et lancer des tests, le tout de
manière automatisée, garantissant une intégration et un déploiement
continus.
○​ Exemple pratique :
■​ Jenkins déclenche le job à partir d’une modification dans Bitbucket.
■​ Une commande comme .\[Link] pack --project
"chemin\vers\projet" est exécutée pour créer le package.
■​ Ensuite, une commande .\[Link] deploy --package
"chemin\vers\package" déploie le package sur Orchestrator.
■​ Enfin, des commandes pour exécuter des tests ou lancer des jobs
peuvent être lancées, automatisant ainsi le cycle complet.
●​ Avantages de l’intégration via la CLI
○​ Réduction des interventions manuelles et des risques d’erreurs humaines.
○​ Meilleure traçabilité et répétabilité des déploiements.
○​ Facilité de personnalisation et d’automatisation grâce à une interface en ligne
de commande intégrable dans divers outils CI/CD comme Jenkins.

Ces fonctionnalités permettent d’automatiser et d’optimiser le cycle de développement et de

déploiement de vos automatisations UiPath dans un environnement CI/CD.

o3-mini-high

Vous avez dit :

je veux mettre en place la CLI uipath sur mon serveur Jenkins, peux tu me faire le cahier
des charge me permettant d'eefectuer cela
Raisonner sur l'installation de la CLI UiPath sur Jenkins pendant 11 secondes

Voici un cahier des charges détaillé sous forme de liste à puces, qui vous permettra
d’intégrer la CLI UiPath dans votre serveur Jenkins pour automatiser le packaging, le
déploiement et l’exécution de tests sur Orchestrator :

●​ Contexte et objectifs
○​ Automatiser l’ensemble du cycle de vie des projets UiPath (packaging,
déploiement, tests).
○​ Intégrer cette automatisation dans votre pipeline CI/CD sous Jenkins pour
améliorer la rapidité, la traçabilité et la fiabilité des déploiements.
●​ Environnement technique
○​ Serveur Jenkins :
■​ Version recommandée (par exemple, Jenkins 2.x ou supérieure).
■​ Agents de build sous Windows (pour utiliser la version
[Link]).
○​ Prérequis logiciels :
■​ Installation de .NET Desktop Runtime (version 6.0.7) sur l’agent.
■​ Accès Internet pour télécharger la CLI depuis le flux public UiPath.
○​ Accès et authentifications :
■​ Accès au dépôt Bitbucket (source du code).
 ■​ Accès et droits sur l’Orchestrator UiPath (création de packages,
déploiement, exécution de tests).
■​ Configuration des credentials via Jenkins Credentials Plugin pour
stocker de façon sécurisée les clés et secrets nécessaires.
●​ Fonctionnalités attendues
○​ Packaging automatisé :
■​ Utilisation de la commande « pack » pour convertir le projet Studio en
package NuGet.
○​ Déploiement sur Orchestrator :
■​ Utilisation de la commande « deploy » pour déployer automatiquement
le package sur Orchestrator.
○​ Exécution de tests et jobs :
■​ Lancement de tests automatisés via la commande « run test » ou le
déclenchement de jobs pour valider le déploiement.
○​ Gestion de version :
■​ Mise à jour automatique du numéro de version lors de chaque
packaging ou déploiement.
○​ Reporting et logs :
■​ Capturer et stocker les logs d’exécution pour analyse et traçabilité.
■​ Mise en place de notifications (email, Slack, etc.) en cas de succès ou
d’échec des jobs.
●​ Étapes d’implémentation
○​ Installation de la CLI sur l’agent Jenkins
■​ Télécharger la CLI UiPath depuis le flux public (exemple de lien pour
[Link] version 23.10.8753.32995 :​
[Link]
cial/NuGet/[Link]/versions/23.10.8753.32995).
■​ Extraire le package et placer l’exécutable ([Link]) dans un
répertoire dédié sur l’agent.
■​ Tester l’exécution en ligne de commande via PowerShell (exemple :
.\[Link] --version).
○​ Configuration de Jenkins
■​ Créer un job ou pipeline dédié à l’intégration de la CLI UiPath.
■​ Ajouter des étapes de build dans le pipeline pour :
■​ Packaging : exécuter la commande de packaging (ex. :
.\[Link] pack --project "chemin\vers\projet" --output
"chemin\vers\output").
■​ Déploiement : exécuter la commande de déploiement (ex. :
.\[Link] deploy --package "chemin\vers\package"
--orchestratorUrl "URL_Orchestrator" …).
■​ Exécution de tests : lancer des tests post-déploiement (ex. :
.\[Link] runtest --package "chemin\vers\package").
■​ Paramétrer les variables d’environnement et les secrets nécessaires
pour l’authentification (client id, client secret, etc.).
○​ Intégration dans le pipeline CI/CD
■​ Orchestrer les différentes étapes en fonction des triggers (par
exemple, déclencher le pipeline à chaque commit ou à chaque fusion
dans la branche cible).
 ■​ Assurer une gestion d’erreurs robuste : capture des logs, rollback en
cas d’échec, notifications automatisées.
●​ Sécurité et gestion des accès
○​ Stocker de manière sécurisée les credentials via Jenkins Credentials Plugin.
○​ Mettre en place des politiques de sécurité sur l’agent Jenkins pour limiter
l’accès aux exécutables et aux scripts.
○​ S’assurer que l’utilisateur ou le compte de service utilisé pour le déploiement
dispose uniquement des permissions nécessaires sur Orchestrator.
●​ Documentation et formation
○​ Rédiger une documentation interne détaillant :
■​ L’installation et la configuration de la CLI sur l’agent Jenkins.
■​ La structure du pipeline Jenkins intégrant les commandes de la CLI.
■​ Les bonnes pratiques de gestion des credentials et de suivi des logs.
○​ Organiser une session de formation ou une revue technique avec l’équipe
DevOps pour s’assurer de la bonne compréhension et de la prise en main
des nouvelles automatisations.
●​ Maintenance et support
○​ Planifier des mises à jour régulières de la CLI pour bénéficier des dernières
fonctionnalités et corrections de bugs.
○​ Mettre en place un monitoring des jobs Jenkins afin de détecter rapidement
toute anomalie.
○​ Prévoir un processus de revue et de mise à jour de la documentation en cas
d’évolution de l’outil ou des processus internes.
●​ Planning et livrables
○​ Phase 1 : Préparation et installation
■​ Mise en place de l’environnement (agents, prérequis logiciels, accès).
■​ Installation de la CLI et tests de fonctionnement en standalone.
○​ Phase 2 : Intégration et développement
■​ Développement et configuration des jobs/pipelines Jenkins intégrant
la CLI.
■​ Tests d’intégration sur un environnement de test.
○​ Phase 3 : Documentation et formation
■​ Rédaction du guide d’installation et d’utilisation.
■​ Formation des équipes concernées.
○​ Phase 4 : Déploiement en production et monitoring
■​ Passage en production.
■​ Mise en place du monitoring et support post-déploiement.

Ce cahier des charges vous fournira une feuille de route détaillée pour l’intégration de la CLI
UiPath dans votre environnement Jenkins, garantissant ainsi une automatisation fiable et
sécurisée de vos déploiements.

Voici un cahier des charges actualisé intégrant la problématique de coexistence de versions

de .NET Desktop Runtime sur votre serveur Jenkins :
Contexte et objectifs
Automatiser le cycle de vie des projets UiPath (packaging, déploiement, tests) via la CLI
UiPath.
Intégrer cette automatisation dans un pipeline CI/CD Jenkins afin d’améliorer la rapidité et la
fiabilité des déploiements.
Environnement technique
Serveur Jenkins
Version recommandée : Jenkins 2.x ou supérieure.
Agents de build sous Windows (pour utiliser la version [Link]).
Prérequis logiciels
Installation de .NET Desktop Runtime requis par la CLI (exemple : .NET 6.0.7 Desktop
Runtime).
Vérifier la présence d’autres versions de .NET Desktop Runtime déjà utilisées par certains
plugins Jenkins.
Accès et authentifications
Accès au dépôt Bitbucket pour le code source.
Droits sur l’Orchestrator UiPath pour le déploiement, la publication et l’exécution de tests.
Gestion sécurisée des credentials via le Jenkins Credentials Plugin.
Fonctionnalités attendues
Packaging automatisé
Exécution de la commande « pack » pour convertir un projet UiPath Studio en package
NuGet.
Déploiement sur Orchestrator
Exécution de la commande « deploy » pour envoyer le package sur Orchestrator.
Exécution de tests et déclenchement de jobs
Lancement de tests automatisés ou de jobs post-déploiement via la commande « run test »
ou équivalent.
Gestion de version
Incrémentation automatique du numéro de version lors du packaging/déploiement.
Reporting et logs
Capture et stockage des logs d’exécution pour suivi et traçabilité.
Notifications (email, Slack…) en cas d’échec ou de succès.
Gestion des conflits de versions .NET Desktop Runtime
Côté système Windows
Windows permet l’installation côte à côte de plusieurs versions de .NET Desktop Runtime.
Assurez-vous que la version spécifique requise par la CLI (par exemple, .NET 6.0.7) est
installée parallèlement à l’autre version déjà présente.
Isolation et tests de compatibilité
Vérifiez que l’exécutable de la CLI ([Link]) utilise bien la version de .NET pour laquelle il
a été compilé.
Testez les plugins Jenkins existants afin de vous assurer qu’ils continuent à fonctionner avec
leur version de .NET.
Si des conflits apparaissent ou si les plugins sensibles posent problème, envisagez
l’utilisation d’un agent Jenkins dédié ou d’un conteneur pour isoler l’environnement de la
CLI.
Documentation et support
Consulter la documentation de chaque plugin Jenkins pour confirmer leurs prérequis .NET.
Mettre en place une procédure de rollback ou de test de non-régression afin de valider
qu’aucun service n’est impacté par l’installation parallèle.
Étapes d’implémentation
Installation de la CLI sur l’agent Jenkins
Télécharger la CLI UiPath depuis le flux public (exemple pour [Link] version
23.10.8753.32995 :
[Link]
.Windows/versions/23.10.8753.32995 ).
Extraire le package et placer l’exécutable dans un répertoire dédié sur l’agent Jenkins.
Vérifier l’exécution via PowerShell (exemple : .\[Link] --version).
Configuration du pipeline Jenkins
Créer un job ou pipeline dédié qui intègre les étapes de packaging, déploiement et tests.
Ajouter une étape pour définir les variables d’environnement et spécifier le chemin de
l’exécutable de la CLI.
Configurer les scripts pour appeler les commandes de la CLI (pack, deploy, runtest) en
gérant les retours et erreurs.
Gestion de l’environnement .NET
Installer la version requise (.NET 6.0.7 Desktop Runtime) en parallèle de l’autre version.
Tester que l’agent Jenkins peut lancer la CLI sans interférer avec les autres plugins qui
utilisent une version différente.
Intégration et tests
Exécuter des tests d’intégration sur un environnement de pré-production pour valider la
coexistence des versions de .NET et le bon fonctionnement de la CLI.
Vérifier les logs et corriger les éventuels problèmes de compatibilité.
Sécurité et gestion des accès
Stocker les credentials et secrets de manière sécurisée avec le Jenkins Credentials Plugin.
Limiter les accès aux scripts et exécutables via des politiques de sécurité sur l’agent.
Documentation et formation
Rédiger un guide détaillé pour l’installation, la configuration et la gestion des versions
multiples de .NET.
Organiser une session de formation pour l’équipe DevOps sur le déploiement et la
maintenance de la CLI dans l’environnement Jenkins.
Maintenance et support
Planifier des mises à jour régulières de la CLI et des composants .NET.
Mettre en place un monitoring des jobs Jenkins pour détecter rapidement toute anomalie liée
à la coexistence des versions de .NET.
Prévoir des procédures de rollback en cas de conflits non résolus.
En résumé, ce cahier des charges vous offre une feuille de route pour installer la CLI UiPath
sur Jenkins tout en prenant en compte la coexistence de différentes versions de .NET
Desktop Runtime. Bien que Windows permette une installation côte à côte, des tests
approfondis et éventuellement une isolation par agent ou conteneur sont recommandés pour
garantir la compatibilité avec l’ensemble des plugins Jenkins déjà en place.
Peux tu m'aider pour mettre en place la cli uipath?

Bien sûr, je vais vous guider étape par étape pour mettre en place la CLI UiPath dans votre

environnement Jenkins tout en prenant en compte les prérequis liés à la coexistence des

versions de .NET Desktop Runtime .

1. Préparation de l'environnement

a. Vérification des prérequis

Avant de commencer, assurez-vous que :

●​ Le serveur Jenkins est installé (version 2.x ou supérieure).

●​ Les agents de build sous Windows sont configurés.
●​ Vous disposez des droits nécessaires pour installer des logiciels sur les agents
Jenkins.

b. Installation de .NET Desktop Runtime

La CLI UiPath nécessite une version spécifique de .NET Desktop Runtime (par exemple,

.NET 6.0.7 ). Voici comment procéder :

1.​ Vérifiez les versions existantes :

●​ Ouvrez une invite de commande PowerShell et exécutez :
●​ powershell
●​ Copy
●​ 1
●​ Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework
Setup\NDP' -Recurse | Get-ItemProperty -Name Version -EA
0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} |
Select PSChildName, Version
●​ Cela vous permettra d’identifier les versions déjà installées.
2.​ Installez la version requise (.NET 6.0.7) :
●​ Téléchargez le runtime depuis le site officiel Microsoft :
●​ .NET 6.0 Desktop Runtime
●​ 4
●​ .
●​ Installez-le en suivant les instructions. Windows prend en charge l'installation
côte à côte de plusieurs versions de .NET Desktop Runtime.
3.​ Testez l’isolation des versions :
●​ Assurez-vous que l’exécutable [Link] utilise bien la version requise.
Vous pouvez vérifier cela avec :
●​ powershell
●​ Copy
●​ 1
●​ .\[Link] --version

2. Installation de la CLI UiPath

a. Téléchargement de la CLI
 1.​ Accédez au flux public d’UiPath pour télécharger la version souhaitée de la CLI :
●​ Exemple : [Link] version 23.10.8753.32995 .
2.​ Extrayez le package téléchargé dans un répertoire dédié sur l’agent Jenkins, par
exemple :
3.​ Copy
4.​ 1
5.​ C:\Jenkins\CLI\UiPath

b. Configuration de l’environnement
1.​ Ajoutez le chemin de la CLI (C:\Jenkins\CLI\UiPath) à la variable d’environnement
PATH de l’agent Jenkins.
2.​ Testez l’exécution de la CLI :
3.​ powershell
4.​ Copy
5.​ 1
6.​ [Link] --version

3. Configuration du pipeline Jenkins

a. Création d’un pipeline

1.​ Dans Jenkins, créez un nouveau pipeline (ou job).
2.​ Configurez les étapes suivantes dans votre pipeline :

pipeline {
agent any

environment {
UIPATH_CLI_PATH = "C:\\Jenkins\\CLI\\UiPath\\[Link]"
ORCHESTRATOR_URL = "[Link]
ORCHESTRATOR_TENANT = "your-tenant"
ORCHESTRATOR_USER = credentials('orchestrator-username')
ORCHESTRATOR_PASSWORD =
credentials('orchestrator-password')
}

stages {
stage('Packaging') {
steps {
script {
 bat "${UIPATH_CLI_PATH} pack --project-path
\"${WORKSPACE}\\YourProjectFolder\" --output-path
\"${WORKSPACE}\""
}
}
}

stage('Deployment') {
steps {
script {
bat "${UIPATH_CLI_PATH} deploy --package
\"${WORKSPACE}\\[Link]\" --url ${ORCHESTRATOR_URL}
--tenant ${ORCHESTRATOR_TENANT} --user ${ORCHESTRATOR_USER}
--password ${ORCHESTRATOR_PASSWORD}"
}
}
}

stage('Run Tests') {
steps {
script {
bat "${UIPATH_CLI_PATH} run test --process-name
YourProcessName --url ${ORCHESTRATOR_URL} --tenant
${ORCHESTRATOR_TENANT} --user ${ORCHESTRATOR_USER} --password
${ORCHESTRATOR_PASSWORD}"
}
}
}
}

post {
success {
echo "Pipeline completed successfully."
}
failure {
echo "Pipeline failed."
}
}
}
b. Gestion des credentials
●​ Utilisez le Jenkins Credentials Plugin pour stocker les identifiants de l’Orchestrator
UiPath de manière sécurisée.
●​ Remplacez credentials('orchestrator-username') et
credentials('orchestrator-password') par les identifiants appropriés.

4. Tests et validation

a. Validation de la coexistence des versions .NET

●​ Testez que les plugins Jenkins existants continuent de fonctionner correctement avec
leurs versions respectives de .NET.
●​ Si des conflits apparaissent, envisagez d’utiliser un agent Jenkins dédié ou un
conteneur Docker pour isoler l’environnement de la CLI.

b. Tests d’intégration
●​ Exécutez le pipeline sur un environnement de pré-production pour valider :
●​ La coexistence des versions de .NET.
●​ Le bon fonctionnement des commandes pack, deploy, et run test.

5. Documentation et maintenance

a. Documentation
●​ Rédigez un guide détaillé incluant :
●​ Les étapes d’installation de la CLI et de .NET Desktop Runtime.
●​ La configuration du pipeline Jenkins.
●​ Les procédures de rollback en cas de problème.

b. Maintenance
●​ Planifiez des mises à jour régulières de la CLI et des composants .NET.
●​ Mettez en place un monitoring pour détecter rapidement les anomalies.

6. Points supplémentaires à surveiller

●​ Si vous rencontrez des erreurs lors de l’installation de .NET Desktop Runtime,
consultez les solutions proposées dans les forums ou la documentation officielle
●​ 6
●​ .
 ●​ En cas de problèmes de compatibilité avec les plugins Jenkins, référez-vous à leur
documentation respective pour vérifier leurs prérequis .NET
●​ 8
●​ .

En suivant ces étapes, vous devriez être en mesure de configurer la CLI UiPath dans

Jenkins tout en gérant efficacement la coexistence des versions de .NET Desktop Runtime.

Si vous avez besoin d’aide supplémentaire pour une étape spécifique, n’hésitez pas à

demander !

si d'autres plugins jenkins utilise une version differente de .NET Desktop Runtime (version

6.0.7), est ce un probleme?

Non, en général, ce n'est pas un problème si d'autres plugins Jenkins utilisent une version

différente de .NET Desktop Runtime , car Windows prend en charge l'installation côte à côte

(side-by-side) de plusieurs versions de .NET Runtime. Cela signifie que différentes

applications ou plugins peuvent utiliser des versions spécifiques de .NET sans interférer les

uns avec les autres

Cependant, il est important de prendre certaines précautions pour garantir que tout

fonctionne correctement :

1. Vérification de la compatibilité des plugins

●​ Certains plugins Jenkins peuvent avoir des dépendances strictes sur une version
spécifique de .NET. Consultez la documentation de chaque plugin pour confirmer ses
prérequis
●​ 2
●​ .
●​ Si un plugin nécessite une version spécifique de .NET (par exemple, .NET
Framework 4.x), assurez-vous que cette version est installée et qu'elle ne sera pas
remplacée ou désinstallée lors de l'ajout de .NET Desktop Runtime 6.0.7 .

2. Isolation des environnements

 ●​ Bien que Windows permette l'installation côte à côte, des conflits peuvent survenir si
plusieurs processus tentent d'accéder simultanément à des versions incompatibles
de .NET. Pour éviter cela :
●​ Utilisez des agents Jenkins dédiés : Configurez un agent Jenkins spécifique
pour exécuter les tâches liées à la CLI UiPath. Cela garantit que cet agent
dispose uniquement des versions de .NET nécessaires pour la CLI, sans
interférence avec d'autres plugins.
●​ Utilisez des conteneurs Docker : Encapsulez l'environnement de la CLI
UiPath dans un conteneur Docker qui inclut uniquement .NET Desktop
Runtime 6.0.7 . Cela isole complètement l'exécution de la CLI des autres
plugins Jenkins.

3. Tests de coexistence
●​ Après avoir installé .NET Desktop Runtime 6.0.7 , testez les plugins Jenkins
existants pour vous assurer qu'ils continuent de fonctionner correctement avec leurs
versions respectives de .NET
●​ 3
●​ .
●​ Exécutez également des tests d'intégration pour vérifier que la CLI UiPath fonctionne
comme prévu avec .NET Desktop Runtime 6.0.7 sans affecter les autres plugins.

4. Gestion des erreurs potentielles

●​ Si des erreurs surviennent après l'installation de .NET Desktop Runtime 6.0.7 , elles
peuvent être liées à des problèmes de configuration ou de compatibilité. Par exemple
:
●​ Une erreur indiquant que "la version de .NET Runtime ne peut pas être
antérieure à la version requise" peut signifier qu'un plugin ou une application
nécessite une mise à jour pour fonctionner avec la nouvelle version
●​ 1
●​ .
●​ Dans ce cas, envisagez de réinstaller ou de corriger la version spécifique de
.NET requise par le plugin concerné
●​ 6
●​ .

5. Bonnes pratiques
 ●​ Planifiez des tests en pré-production : Avant de déployer la CLI UiPath et .NET
Desktop Runtime 6.0.7 dans un environnement de production, effectuez des tests
approfondis dans un environnement isolé pour valider la coexistence des versions de
.NET.
●​ Documentez les configurations : Tenez une trace des versions de .NET installées et
des plugins Jenkins qui en dépendent. Cela facilitera le dépannage en cas de
problème.

Conclusion
En résumé, l'utilisation de plusieurs versions de .NET Desktop Runtime (comme 6.0.7 pour

la CLI UiPath et d'autres versions pour les plugins Jenkins) n'est généralement pas un

problème grâce à l'installation côte à côte prise en charge par Windows. Cependant, des

précautions telles que l'isolation des environnements et les tests de compatibilité sont

essentielles pour éviter tout conflit potentiel.

"Si un plugin nécessite une version spécifique de .NET (par exemple, .NET Framework 4.x),

assurez-vous que cette version est installée et qu'elle ne sera pas remplacée ou désinstallée

lors de l'ajout de .NET Desktop Runtime 6.0.7 " c'est a dire je croyaiis que c'etait du side by

side??

Vous avez tout à fait raison de souligner que Windows prend en charge l'installation côte à

côte (side-by-side) pour plusieurs versions de .NET Runtime et .NET Framework .

Cependant, il existe des nuances importantes à comprendre entre les différentes versions

de .NET, notamment entre .NET Framework (par exemple, 4.x) et .NET Desktop Runtime

(comme .NET 6.0.7). Voici une explication détaillée pour clarifier ce point :

1. Compatibilité côte à côte : .NET Framework vs .NET

Core/Desktop Runtime
●​ .NET Framework (versions 3.5, 4.x) :
●​ Les versions du .NET Framework 4.x sont compatibles côte à côte avec
certaines limitations. Par exemple, une seule version majeure du .NET
Framework 4.x peut être installée sur un système Windows à la fois
●​ 1
 ●​ . Si vous installez une version plus récente (par exemple, .NET Framework
4.8), elle remplace la version précédente (par exemple, .NET Framework
4.6). Cela signifie qu'il n'est pas possible d'avoir simultanément .NET
Framework 4.6 et 4.8 sur le même système.
●​ Toutefois, .NET Framework 3.5 peut coexister avec les versions 4.x, car elles
utilisent des modèles d'exécution différents.
●​ .NET Core/Desktop Runtime (versions 5, 6, etc.) :
●​ Contrairement au .NET Framework , les versions de .NET Core et .NET
Desktop Runtime (comme .NET 6.0.7) sont conçues pour fonctionner en
mode côte à côte complet . Cela signifie que vous pouvez installer plusieurs
versions (par exemple, .NET 5, .NET 6, .NET 7) sans qu'elles ne se
remplacent ou interfèrent entre elles
●​ 4
●​ .

2. Pourquoi mentionner la possibilité de remplacement ?

Dans votre cas, si un plugin Jenkins dépend d'une version spécifique de .NET Framework

4.x , il est important de vérifier que cette version reste intacte lors de l'installation de .NET

Desktop Runtime 6.0.7 . Voici pourquoi cette précaution est mentionnée :

●​ Cas où le plugin utilise .NET Framework 4.x :

●​ Si un plugin Jenkins dépend d'une version spécifique de .NET Framework 4.x
(par exemple, 4.6), et si vous installez accidentellement une mise à jour ou
une version incompatible du .NET Framework (par exemple, 4.8), cela
pourrait entraîner des dysfonctionnements du plugin
●​ 1
●​ .
●​ Bien que .NET Desktop Runtime 6.0.7 ne devrait pas affecter directement
.NET Framework 4.x , il est toujours prudent de vérifier que les versions
requises par les plugins Jenkins restent stables.
●​ Cas où le plugin utilise .NET Core/Desktop Runtime :
●​ Si un plugin Jenkins dépend d'une version spécifique de .NET Core/Desktop
Runtime (par exemple, .NET 5), il n'y a généralement aucun risque de conflit,
car ces versions peuvent coexister sans problème
●​ 4
●​ .

3. Comment éviter les problèmes potentiels ?

Pour garantir que les plugins Jenkins continuent de fonctionner correctement :
 1.​ Vérifiez les prérequis des plugins :
●​ Consultez la documentation de chaque plugin pour identifier ses
dépendances spécifiques en matière de .NET (Framework ou Core/Runtime).
2.​ Installez uniquement les versions nécessaires :
●​ Si un plugin nécessite .NET Framework 4.6 , assurez-vous que cette version
est bien présente sur le système avant d'installer .NET Desktop Runtime
6.0.7 .
3.​ Testez après installation :
●​ Après avoir ajouté .NET Desktop Runtime 6.0.7 , testez les plugins Jenkins
existants pour confirmer qu'ils continuent de fonctionner comme prévu.
4.​ Utilisez des agents Jenkins isolés :
●​ Si vous craignez des conflits, configurez un agent Jenkins dédié pour
exécuter les tâches liées à la CLI UiPath. Cet agent peut inclure uniquement
les versions de .NET nécessaires pour la CLI, sans interférer avec les autres
plugins.

4. Conclusion
En résumé :

●​ .NET Framework 4.x ne prend pas en charge l'installation côte à côte entre ses
versions majeures (par exemple, 4.6 et 4.8). Une mise à jour peut remplacer la
version précédente
●​ 1
●​ .
●​ .NET Desktop Runtime 6.0.7 (basé sur .NET Core) est conçu pour fonctionner en
mode côte à côte complet, ce qui signifie qu'il peut coexister avec d'autres versions
de .NET sans problème
●​ 4
●​ .
La mention de "remplacement" dans ma réponse précédente visait à attirer votre attention

sur les plugins qui dépendent de .NET Framework 4.x , car ces versions peuvent être

sensibles aux mises à jour ou modifications. En revanche, pour .NET Desktop Runtime ,

vous pouvez installer plusieurs versions sans risque de conflit.

de quoi tu me parle??? je parle de NET Desktop Runtime 6.0.7 pourquoi tu m'embrouille

avec .NET Framework et .NET Core

Je comprends votre frustration, et je vais clarifier les choses pour vous. Vous avez raison de

dire que nous parlons spécifiquement de .NET Desktop Runtime 6.0.7 , et non de .NET

Framework ou .NET Core en général. Cependant, il est important de faire la distinction entre
ces termes pour éviter toute confusion, car ils sont souvent mentionnés ensemble dans les

discussions techniques.

Voici une explication concise et directe :

1. Qu'est-ce que .NET Desktop Runtime 6.0.7 ?

●​ .NET Desktop Runtime 6.0.7 fait partie de la famille .NET 6 , qui est une version
moderne de .NET basée sur .NET Core
●​ 2
●​ .
●​ Il est conçu pour exécuter des applications desktop Windows (WPF et WinForms)
développées avec .NET 6.
●​ Contrairement à .NET Framework , .NET Desktop Runtime prend en charge
l'installation côte à côte complète. Cela signifie que vous pouvez installer plusieurs
versions de .NET Desktop Runtime (par exemple, 6.0.7, 7.0, etc.) sans qu'elles ne se
remplacent ou interfèrent entre elles
●​ 8
●​ .

2. Pourquoi j'ai mentionné .NET Framework et .NET Core

?
J'ai mentionné .NET Framework et .NET Core uniquement pour expliquer les différences

entre les versions de .NET, car :

●​ Certains plugins Jenkins peuvent encore dépendre de .NET Framework (par

exemple, 4.x), qui fonctionne différemment de .NET Desktop Runtime .
●​ .NET Framework ne prend pas en charge l'installation côte à côte entre ses versions
majeures (par exemple, 4.6 et 4.8). Si un plugin Jenkins dépend d'une version
spécifique de .NET Framework , il est important de s'assurer que cette version reste
intacte lors de l'installation de .NET Desktop Runtime 6.0.7
●​ 1
●​ .
3. Réponse directe à votre question : Est-ce que .NET
Desktop Runtime 6.0.7 pose problème avec d'autres
versions ?
Non, .NET Desktop Runtime 6.0.7 ne pose généralement pas de problème avec d'autres

versions de .NET Desktop Runtime ou .NET Core , car :

●​ Les versions de .NET Desktop Runtime sont conçues pour coexister sans conflit. Par
exemple, vous pouvez avoir .NET Desktop Runtime 5.0 , 6.0.7 , et 7.0 installés
simultanément sur le même système
●​ 7
●​ .
●​ Chaque application utilise la version spécifique dont elle a besoin, sans interférer
avec les autres versions.

4. Que faire si un plugin Jenkins utilise une autre version

de .NET ?
●​ Si un plugin Jenkins utilise .NET Framework 4.x , cela ne devrait pas poser de
problème, car .NET Framework et .NET Desktop Runtime sont deux technologies
distinctes qui coexistent sans conflit
●​ 8
●​ .
●​ Si un plugin Jenkins utilise une autre version de .NET Desktop Runtime (par
exemple, 5.0 ou 7.0), il n'y aura pas de conflit non plus, car les versions sont isolées
les unes des autres
●​ 4
●​ .

5. Conclusion
Pour résumer :

●​ .NET Desktop Runtime 6.0.7 peut être installé en parallèle avec d'autres versions de
.NET Desktop Runtime ou .NET Core sans aucun problème
●​ 7
●​ .
 ●​ Les plugins Jenkins qui dépendent de .NET Framework 4.x ne seront pas affectés,
car .NET Framework et .NET Desktop Runtime sont des technologies différentes qui
coexistent sur Windows
●​ 8
●​ .
Si vous avez encore des doutes ou des questions spécifiques, n'hésitez pas à demander !

😊
fais moi un document pour cette installation d ela CLIuipath

Voici un document détaillé pour l'installation de la CLI UiPath sur un serveur Jenkins, en

tenant compte des prérequis et des bonnes pratiques. Ce guide vous permettra de

configurer l'environnement et d'intégrer la CLI dans un pipeline Jenkins.

Guide d'Installation de la CLI

UiPath
1. Introduction
La CLI UiPath est une interface en ligne de commande qui permet d'exécuter des tâches

automatisées telles que le packaging, le déploiement et les tests d'automatisation UiPath

. Ce guide explique comment installer et configurer la CLI UiPath sur un serveur Jenkins tout

en gérant les dépendances nécessaires, notamment .NET Desktop Runtime 6.0.7 .

2. Prérequis

a. Environnement système
●​ Serveur Jenkins (version 2.x ou supérieure).
●​ Agents de build sous Windows.
●​ Accès administratif pour installer des logiciels sur les agents Jenkins.
b. Dépendances logicielles
●​ .NET Desktop Runtime 6.0.7 : Requis pour exécuter la CLI UiPath
●​ 1
●​ .
●​ Plugins Jenkins nécessaires :
●​ Jenkins Credentials Plugin pour gérer les identifiants sécurisés.
●​ UiPath Automation Package Plugin (optionnel) pour simplifier l'intégration
●​ 7
●​ .

c. Accès et authentifications
●​ Accès au dépôt Bitbucket ou Git pour récupérer le code source.
●​ Droits sur l’Orchestrator UiPath pour le déploiement, la publication et l’exécution de
tests.

3. Étapes d'Installation

Étape 1 : Installation de .NET Desktop Runtime 6.0.7

1.​ Téléchargez .NET Desktop Runtime 6.0.7 depuis le site officiel Microsoft :
●​ Télécharger .NET Desktop Runtime
●​ 1
●​ .
2.​ Installez-le en suivant les instructions du programme d'installation.
3.​ Vérifiez l'installation en exécutant la commande suivante dans PowerShell :
4.​
5.​ dotnet --list-runtimes
6.​ Assurez-vous que [Link] 6.0.7 apparaît dans la liste.

Étape 2 : Téléchargement de la CLI UiPath

1.​ Accédez au flux public d’UiPath pour télécharger la version souhaitée de la CLI :
●​ Exemple : [Link] version 23.10.8753.32995
●​ 1
●​ .
2.​ Extrayez le package téléchargé dans un répertoire dédié sur l’agent Jenkins, par
exemple :
3.​
 4.​ C:\Jenkins\CLI\UiPath

Étape 3 : Configuration de l’environnement

1.​ Ajoutez le chemin de la CLI (C:\Jenkins\CLI\UiPath) à la variable d’environnement
PATH de l’agent Jenkins.
2.​ Testez l’exécution de la CLI en exécutant la commande suivante dans PowerShell :
3.​
4.​ [Link] --version
5.​ Vous devriez voir la version de la CLI affichée.

4. Configuration du Pipeline Jenkins

Étape 1 : Création d’un pipeline

1.​ Dans Jenkins, créez un nouveau pipeline.
2.​ Configurez les étapes suivantes dans votre pipeline :

pipeline {
agent any

environment {
UIPATH_CLI_PATH = "C:\\Jenkins\\CLI\\UiPath\\[Link]"
ORCHESTRATOR_URL = "[Link]
ORCHESTRATOR_TENANT = "your-tenant"
ORCHESTRATOR_USER = credentials('orchestrator-username')
ORCHESTRATOR_PASSWORD =
credentials('orchestrator-password')
}

stages {
stage('Packaging') {
steps {
script {
bat "${UIPATH_CLI_PATH} pack --project-path
\"${WORKSPACE}\\YourProjectFolder\" --output-path
\"${WORKSPACE}\""
}
 }
}

stage('Deployment') {
steps {
script {
bat "${UIPATH_CLI_PATH} deploy --package
\"${WORKSPACE}\\[Link]\" --url ${ORCHESTRATOR_URL}
--tenant ${ORCHESTRATOR_TENANT} --user ${ORCHESTRATOR_USER}
--password ${ORCHESTRATOR_PASSWORD}"
}
}
}

stage('Run Tests') {
steps {
script {
bat "${UIPATH_CLI_PATH} run test --process-name
YourProcessName --url ${ORCHESTRATOR_URL} --tenant
${ORCHESTRATOR_TENANT} --user ${ORCHESTRATOR_USER} --password
${ORCHESTRATOR_PASSWORD}"
}
}
}
}

post {
success {
echo "Pipeline completed successfully."
}
failure {
echo "Pipeline failed."
}
}
}

Étape 2 : Gestion des credentials

 1.​ Utilisez le Jenkins Credentials Plugin pour stocker les identifiants de l’Orchestrator
UiPath de manière sécurisée.
2.​ Remplacez credentials('orchestrator-username') et
credentials('orchestrator-password') par les identifiants appropriés.

5. Validation et Tests

Étape 1 : Tests de coexistence

●​ Vérifiez que les plugins Jenkins existants continuent de fonctionner correctement
avec leurs versions respectives de .NET.
●​ Exécutez des tests d'intégration pour valider que la CLI UiPath fonctionne comme
prévu avec .NET Desktop Runtime 6.0.7 .

Étape 2 : Tests d’intégration

●​ Exécutez le pipeline sur un environnement de pré-production pour valider :
●​ La coexistence des versions de .NET.
●​ Le bon fonctionnement des commandes pack, deploy, et run test.

6. Maintenance et Support

a. Mises à jour régulières

●​ Planifiez des mises à jour régulières de la CLI UiPath et des composants .NET pour
garantir la compatibilité avec les nouvelles versions.

b. Monitoring
●​ Mettez en place un monitoring des jobs Jenkins pour détecter rapidement toute
anomalie liée à la coexistence des versions de .NET.

c. Procédures de rollback
●​ Prévoyez des procédures de rollback en cas de conflits non résolus. Par exemple,
conservez une sauvegarde des versions précédentes de .NET et de la CLI.

7. Documentation et Formation
a. Documentation
●​ Rédigez un guide détaillé incluant :
●​ Les étapes d’installation de la CLI et de .NET Desktop Runtime.
●​ La configuration du pipeline Jenkins.
●​ Les procédures de rollback en cas de problème.

b. Formation
●​ Organisez une session de formation pour l’équipe DevOps sur le déploiement et la
maintenance de la CLI dans l’environnement Jenkins.

8. Conclusion
Ce guide vous permet de configurer la CLI UiPath dans Jenkins tout en gérant efficacement

les dépendances liées à .NET Desktop Runtime 6.0.7 . Si vous avez besoin d’aide

supplémentaire pour une étape spécifique, n’hésitez pas à demander !

Références :

●​ 1
●​ : Documentation UiPath sur la CLI et les prérequis.
●​ 5
●​ : Notes sur les fonctionnalités de la CLI UiPath.
●​ 7
●​ : Informations sur le plugin Jenkins UiPath.
une fois la partie effectué sur le serveur jenkins, il faut parametrer l'orchestrator

Oui, une fois que vous avez configuré la CLI UiPath et intégré les pipelines Jenkins pour

automatiser les tâches (packaging, déploiement, tests), il est essentiel de paramétrer UiPath

Orchestrator pour garantir que les processus automatisés puissent être correctement

déployés et exécutés. Voici un guide détaillé pour configurer UiPath Orchestrator en

complément de votre configuration Jenkins.

Guide de Paramétrage de
l'Orchestrator UiPath
1. Introduction
L’Orchestrator UiPath est une plateforme centrale qui permet de gérer, superviser et

exécuter des robots d’automatisation

10

. Une fois que votre serveur Jenkins est configuré pour interagir avec la CLI UiPath, vous

devez configurer l’Orchestrator pour qu’il puisse recevoir les packages, gérer les robots et

exécuter les processus.

2. Prérequis pour Configurer l’Orchestrator

a. Accès à l’Orchestrator
●​ Assurez-vous d’avoir un accès administrateur ou équivalent sur l’Orchestrator
UiPath.
●​ Identifiants valides pour l’authentification (nom d’utilisateur/mot de passe ou jeton
OAuth).

b. Configuration du Tenant
●​ Vérifiez que le tenant approprié est configuré dans l’Orchestrator. Si ce n’est pas le
cas, créez un tenant dédié pour vos projets d’automatisation.

c. Robots et Machines
●​ Les robots UiPath doivent être préalablement installés sur les machines cibles et
connectés à l’Orchestrator
●​ 8
●​ .
●​ Assurez-vous que les machines sont correctement enregistrées dans l’Orchestrator.

3. Étapes de Configuration
Étape 1 : Création d’un Tenant
Si vous n’avez pas encore configuré de tenant :

1.​ Connectez-vous à l’Orchestrator.

2.​ Accédez à Administration > Tenants .
3.​ Cliquez sur Add Tenant et remplissez les informations requises (nom du tenant,
description, etc.).

Étape 2 : Gestion des Robots

1.​ Accédez à Tenants > Machines dans l’Orchestrator.
2.​ Ajoutez les machines sur lesquelles les robots UiPath sont installés :
●​ Renseignez le nom de la machine, son adresse IP, et le type de robot
(Unattended ou Attended).
●​ Associez chaque machine à un robot spécifique
●​ 8
●​ .
3.​ Assurez-vous que les robots sont connectés à l’Orchestrator. Vous pouvez vérifier
leur statut dans la section Robots .

Étape 3 : Configuration des Environnements

Les environnements permettent de regrouper des robots pour exécuter des processus

spécifiques :

1.​ Accédez à Tenants > Environments .

2.​ Créez un nouvel environnement (par exemple, Production , Preprod , etc.).
3.​ Ajoutez les robots appropriés à cet environnement.

Étape 4 : Déploiement des Processus

1.​ Accédez à Processes dans l’Orchestrator.
2.​ Chargez le package NuGet généré par la CLI UiPath via Jenkins :
●​ Utilisez la commande deploy de la CLI pour envoyer le package directement
à l’Orchestrator.
●​ Alternativement, téléchargez manuellement le package dans l’Orchestrator
via l’interface utilisateur.
3.​ Associez le processus à un environnement spécifique.
Étape 5 : Configuration des Triggers
Les triggers permettent d’automatiser l’exécution des processus :

1.​ Accédez à Triggers dans l’Orchestrator.

2.​ Créez un nouveau trigger pour définir :
●​ Le processus à exécuter.
●​ L’environnement cible.
●​ La planification (par exemple, exécution quotidienne à une heure précise).

Étape 6 : Supervision et Reporting

1.​ Utilisez le tableau de bord de l’Orchestrator pour superviser les exécutions des
robots.
2.​ Configurez des alertes pour être notifié en cas d’échec ou d’anomalie.
3.​ Consultez les logs d’exécution pour diagnostiquer les erreurs.

4. Intégration avec Jenkins

a. Authentification
●​ Stockez les identifiants de l’Orchestrator (nom d’utilisateur/mot de passe ou jeton
OAuth) dans le Jenkins Credentials Plugin pour sécuriser les communications entre
Jenkins et l’Orchestrator.

b. Pipeline Jenkins
Dans votre pipeline Jenkins, assurez-vous que les étapes suivantes sont correctement

configurées :

●​ Packaging : Génération du package NuGet.

●​ Déploiement : Envoi du package à l’Orchestrator via la commande deploy.
●​ Exécution : Lancement des processus sur l’Orchestrator via la commande run test.
Exemple de script Jenkins pour le déploiement :

stage('Deployment') {
steps {
script {
bat "${UIPATH_CLI_PATH} deploy --package
\"${WORKSPACE}\\[Link]\" --url ${ORCHESTRATOR_URL}
--tenant ${ORCHESTRATOR_TENANT} --user ${ORCHESTRATOR_USER}
--password ${ORCHESTRATOR_PASSWORD}"
}
}
}

5. Validation et Tests

a. Tests d’intégration
●​ Exécutez un pipeline Jenkins complet pour valider que :
●​ Le package est correctement généré et déployé sur l’Orchestrator.
●​ Le processus est exécuté sur les robots cibles.

b. Supervision
●​ Vérifiez dans l’Orchestrator que les processus s’exécutent comme prévu et que les
logs ne contiennent pas d’erreurs.

6. Maintenance et Support

a. Mises à jour régulières

●​ Gardez l’Orchestrator à jour avec les dernières versions pour bénéficier des
nouvelles fonctionnalités et corrections de bugs.

b. Monitoring
●​ Mettez en place un monitoring pour détecter rapidement toute anomalie liée aux
robots ou aux processus.

7. Conclusion
La configuration de l’Orchestrator UiPath est une étape cruciale pour garantir que vos

processus automatisés soient correctement déployés et exécutés. En combinant cette

configuration avec Jenkins, vous pouvez automatiser entièrement le cycle de vie de vos

projets UiPath, de la génération des packages à l’exécution des processus.

Si vous avez besoin d’aide supplémentaire pour une étape spécifique, n’hésitez pas à

demander !

Références :

●​ 8
●​ : Documentation UiPath sur la gestion des machines et robots dans l’Orchestrator.
●​ 10
●​ : Introduction à UiPath Orchestrator et ses fonctionnalités.
tu embrouille j'ai un orchestrator avec plusieur tenant et plusieur robot, je ne veux pas savoir

comment creer un tenant??? ni comment decrire un robot?? Je veux savoir ce qui faut faire

au niveau orchestrator pour que le cli uipath installer sur Jenkins fonctionne??

Qwen2.5-Max
Je comprends parfaitement votre demande, et je vais me concentrer uniquement sur les

étapes spécifiques à réaliser au niveau de l’Orchestrator UiPath pour que la CLI UiPath

installée sur Jenkins fonctionne correctement. Voici un guide clair et direct :

Configuration de l’Orchestrator UiPath

pour la CLI UiPath
Pour que la CLI UiPath (installée sur Jenkins) puisse interagir avec l’Orchestrator, il est

nécessaire de configurer certains éléments dans l’Orchestrator. Voici les étapes essentielles

1. Vérification des Accès

La CLI UiPath nécessite des identifiants valides pour communiquer avec l’Orchestrator.

Assurez-vous que :

●​ Vous disposez d’un utilisateur avec les droits suffisants pour effectuer des actions
telles que le déploiement de packages, l’exécution de processus, etc.
●​ Si vous utilisez un système d’authentification OAuth2, générez un jeton d’accès
(Access Token) pour sécuriser la communication entre Jenkins et l’Orchestrator
●​ 4
 ●​ .

Étapes :
1.​ Connectez-vous à l’Orchestrator en tant qu’administrateur.
2.​ Accédez à Tenant > Manage Access > Users & Groups .
3.​ Vérifiez que l’utilisateur ou le compte utilisé par Jenkins possède les rôles
appropriés, tels que :
●​ Automation Developer (pour déployer des packages).
●​ Automation Operator (pour exécuter des processus).

2. Configuration de l’URL de l’Orchestrator

La CLI UiPath a besoin de l’URL de l’Orchestrator pour se connecter. Assurez-vous que :

●​ L’URL de l’Orchestrator est accessible depuis le serveur Jenkins.

●​ Si vous utilisez un Orchestrator cloud (UiPath Automation Cloud), l’URL est
généralement sous la forme [Link]
●​ Si vous utilisez un Orchestrator on-premise, vérifiez que l’URL est correcte et
accessible (par exemple, [Link]

3. Association des Robots aux Environnements

Les robots doivent être correctement configurés et associés à des environnements pour

exécuter les processus déployés via la CLI.

Étapes :
1.​ Dans l’Orchestrator, accédez à Tenants > Environments .
2.​ Créez un environnement spécifique pour vos robots (par exemple, Production ,
Preprod , etc.).
3.​ Ajoutez les robots appropriés à cet environnement. Les robots doivent déjà être
enregistrés dans l’Orchestrator
4.​ 3
5.​ .

4. Déploiement des Packages

La CLI UiPath utilise la commande deploy pour envoyer des packages NuGet à

l’Orchestrator. Pour que cela fonctionne :

 ●​ Assurez-vous que l’Orchestrator est configuré pour recevoir des packages NuGet.
●​ Vérifiez que les packages sont correctement associés aux processus dans
l’Orchestrator.

Étapes :
1.​ Accédez à Processes dans l’Orchestrator.
2.​ Chargez un package manuellement pour tester la configuration.
3.​ Associez le package à un environnement spécifique.

5. Configuration des Triggers (Facultatif)

Si vous souhaitez automatiser l’exécution des processus après leur déploiement :

1.​ Accédez à Triggers dans l’Orchestrator.

2.​ Créez un trigger pour définir :
●​ Le processus à exécuter.
●​ L’environnement cible.
●​ La planification (par exemple, exécution quotidienne à une heure précise).

6. Supervision et Logs
Pour garantir que tout fonctionne correctement :

1.​ Utilisez le tableau de bord de l’Orchestrator pour superviser les exécutions des
robots.
2.​ Configurez des alertes pour être notifié en cas d’échec ou d’anomalie.
3.​ Consultez les logs d’exécution pour diagnostiquer les erreurs.

7. Test de la CLI UiPath avec l’Orchestrator

Une fois l’Orchestrator configuré, testez la CLI UiPath depuis Jenkins pour valider la

connexion :

1.​ Exécutez la commande suivante pour vérifier la connexion :

2.​
3.​ [Link] deploy --package "[Link]" --url
[Link] --tenant YourTenant --user
YourUsername --password YourPassword
4.​ Vérifiez que le package est correctement déployé dans l’Orchestrator.
8. Conclusion
En résumé, voici les points clés à configurer dans l’Orchestrator pour que la CLI UiPath

fonctionne avec Jenkins :

1.​
Accès utilisateur : Assurez-vous que Jenkins dispose des droits nécessaires.
2.​
URL de l’Orchestrator : Vérifiez que l’URL est accessible depuis Jenkins.
3.​
Robots et environnements : Associez les robots aux environnements appropriés.
4.​
Déploiement de packages : Configurez l’Orchestrator pour recevoir les packages
NuGet.
5.​ Supervision :
ce n'est pas ce que je veux !!! tu es a coté de la plaque, tu repond de la merde !!! Je veux

savoir quel est le parametrage a metrre en place pour que le cli uipath fonctionne?

2/2

Qwen2.5-Max
Je comprends votre frustration, et je vais répondre directement à votre question sans détour.

Voici exactement ce que vous devez configurer dans l’Orchestrator UiPath pour que la CLI

UiPath fonctionne correctement avec Jenkins.

Paramétrage de l’Orchestrator UiPath

pour la CLI UiPath
Pour que la CLI UiPath puisse interagir avec l’Orchestrator UiPath depuis Jenkins, voici les

paramètres essentiels à vérifier ou configurer dans l’Orchestrator :

1. Authentification
La CLI UiPath nécessite des identifiants valides pour se connecter à l’Orchestrator. Vous

devez configurer l’une des méthodes d’authentification suivantes :

Option 1 : Utilisateur/Mot de passe

●​ Créez un utilisateur dédié dans l’Orchestrator (ou utilisez un compte existant).
●​ Assurez-vous que cet utilisateur dispose des rôles suivants :
●​ Automation Developer : Pour déployer des packages.
 ●​ Automation Operator : Pour exécuter des processus
●​ 2
●​ .
●​ Stockez ces identifiants dans Jenkins (via le Credentials Plugin ) pour une utilisation
sécurisée.

Option 2 : Jeton OAuth2 (recommandé)

●​ Générez un jeton OAuth2 dans l’Orchestrator pour sécuriser la communication entre
Jenkins et l’Orchestrator.
●​ Accédez à Tenant > Manage Access > API Access dans l’Orchestrator.
●​ Créez un client OAuth2 et générez un jeton d’accès.
●​ Utilisez ce jeton dans vos commandes CLI UiPath via Jenkins.

2. URL de l’Orchestrator
●​ Vérifiez que l’URL de l’Orchestrator est accessible depuis le serveur Jenkins.
●​ Pour un Orchestrator cloud : [Link]
●​ Pour un Orchestrator on-premise : [Link]
●​ Testez la connexion depuis Jenkins en utilisant la commande suivante :
●​ powershell
●​ Copy
●​ 1
●​ [Link] login --url [Link]
bon tu ne semble pas comprendre !!! il faut declarer au niveau de l'orchestrator une

application externe

bon tu ne semble pas comprendre !!! il faut declarer au niveau de l'orchestrator une

application externe

Je comprends maintenant ce que vous attendez. Vous avez raison, pour permettre à la CLI

UiPath de fonctionner avec Jenkins, il est nécessaire de déclarer une application externe

dans l’Orchestrator UiPath . Cette étape est cruciale pour authentifier et autoriser les appels

API provenant de Jenkins via la CLI UiPath.

Voici un guide précis pour déclarer une application externe dans l’Orchestrator UiPath ,

comme vous l’avez demandé :

Déclaration d’une Application Externe
dans l’Orchestrator UiPath
Lorsque vous utilisez la CLI UiPath depuis Jenkins, vous devez configurer une application

externe dans l’Orchestrator pour permettre une authentification sécurisée via OAuth2. Voici

les étapes détaillées :

1. Connexion en tant qu’Administrateur

●​ Connectez-vous à l’Orchestrator UiPath en tant qu’administrateur du tenant.
●​ Accédez à Tenant > Manage Access > Applications (Applications externes)
●​ 5
●​ .

2. Création de l’Application Externe

1.​ Cliquez sur Add Application pour créer une nouvelle application externe.
2.​ Remplissez les champs suivants :
●​ Nom de l’application : Donnez un nom explicite, par exemple
Jenkins_CLI_UiPath.
●​ Type d’application : Sélectionnez Confidential (pour les applications qui
nécessitent un secret client).
●​ URI de redirection : Spécifiez l’URI où les jetons seront redirigés. Si vous
n’utilisez pas de redirection spécifique, vous pouvez utiliser un URI factice
comme [Link]
●​ 3
●​ .

3. Attribution des Rôles et des Étendues

Pour que l’application puisse interagir avec l’Orchestrator, vous devez lui attribuer les rôles

et les étendues nécessaires :

Rôles Requis
●​ Attribuez les rôles suivants à l’application :
●​ Automation Developer : Pour déployer des packages.
 ●​ Automation Operator : Pour exécuter des processus
●​ 5
●​ .

Étendues (Scopes)
●​ Ajoutez les étendues suivantes pour permettre l’accès aux API nécessaires :
●​ [Link] : Accès général à l’Orchestrator.
●​ [Link] : Pour afficher et gérer les robots et machines
●​ 1
●​ .
●​ [Link] : Pour accéder aux processus.
●​ [Link] : Pour exécuter des jobs.
●​ [Link] : Pour déployer des packages NuGet.

4. Génération des Clés d’Authentification

1.​ Une fois l’application créée, générez une clé secrète client (Client Secret) :
●​ Cliquez sur Generate Client Secret .
●​ Copiez et stockez cette clé en lieu sûr, car elle sera utilisée dans Jenkins
pour authentifier la CLI UiPath
●​ 2
●​ .
2.​ Notez également l’ID client (Client ID), qui est généré automatiquement lors de la
création de l’application.

5. Configuration dans Jenkins

Avec les informations générées (Client ID et Client Secret), configurez Jenkins pour utiliser

ces identifiants lors des appels à la CLI UiPath :

1.​ Stockez les identifiants dans le Jenkins Credentials Plugin :

●​ Créez un nouveau secret contenant le Client ID et le Client Secret .
2.​ Modifiez votre pipeline Jenkins pour inclure ces informations dans les commandes
CLI UiPath. Par exemple :
3.​
4.​ [Link] deploy --package "[Link]" --url
[Link] --tenant YourTenant --client-id
YourClientId --client-secret YourClientSecret
6. Validation de la Configuration
Pour vérifier que tout fonctionne correctement :

1.​ Testez la connexion entre Jenkins et l’Orchestrator en exécutant une commande CLI
UiPath simple, comme [Link] login.
2.​ Déployez un package ou exécutez un processus pour valider que l’application
externe a bien les autorisations nécessaires.

7. Conclusion
En résumé, voici les étapes essentielles pour déclarer une application externe dans

l’Orchestrator UiPath :

1.​ Créez une application externe dans Tenant > Manage Access > Applications .
2.​ Attribuez les rôles et étendues nécessaires (par exemple, [Link],
[Link])
3.​ 1
4.​ .
5.​ Générez un Client ID et un Client Secret pour authentifier la CLI UiPath.
6.​ Configurez Jenkins pour utiliser ces identifiants lors des appels à la CLI UiPath.
Cela garantira que la CLI UiPath peut interagir avec l’Orchestrator de manière sécurisée et

efficace.

Si vous avez besoin d’aide supplémentaire pour une étape spécifique, n’hésitez pas à

demander ! 😊
[Link] deploy --package "[Link]" --url [Link] --tenant
YourTenant --client-id YourClientId --client-secret YourClientSecret
mais apres jenkins, le pipeline passe par xl release puis xl deploy, on n'attaque par

directement l'orchestrator

Je comprends mieux maintenant votre architecture. Vous utilisez XL Release et XL Deploy

comme intermédiaires entre Jenkins et l’Orchestrator UiPath, ce qui signifie que Jenkins ne

communique pas directement avec l’Orchestrator, mais passe par ces outils pour orchestrer

le déploiement et l’exécution des processus UiPath.

Dans ce contexte, voici comment configurer la CLI UiPath et l’Orchestrator pour fonctionner

dans un pipeline qui inclut Jenkins → XL Release → XL Deploy → Orchestrator UiPath :

Configuration de la CLI UiPath et de
l’Orchestrator pour une Architecture
Jenkins → XL Release → XL Deploy
Pour que la CLI UiPath fonctionne correctement dans cette chaîne d’outils, il est essentiel de

bien configurer les éléments suivants :

1. Configuration de l’Orchestrator UiPath

L’Orchestrator doit être configuré pour accepter les appels provenant de XL Deploy , car

c’est cet outil qui interagira directement avec lui. Voici les étapes :

a. Déclaration d’une Application Externe

Comme mentionné précédemment, vous devez déclarer une application externe dans

l’Orchestrator pour permettre à XL Deploy de communiquer avec lui via OAuth2.

Étapes :
1.​ Connectez-vous à l’Orchestrator en tant qu’administrateur.
2.​ Accédez à Tenant > Manage Access > Applications (Applications externes) .
3.​ Créez une nouvelle application externe :
●​ Nom : XL_Deploy_UiPath.
●​ Type : Confidential .
●​ URI de redirection : Utilisez un URI factice si nécessaire (par exemple,
[Link]
4.​ Attribuez les rôles nécessaires :
●​ Automation Developer : Pour déployer des packages.
●​ Automation Operator : Pour exécuter des processus.
5.​ Ajoutez les étendues requises :
●​ [Link], [Link], [Link], [Link],
[Link].
6.​ Générez un Client ID et un Client Secret pour cette application. Stockez-les en lieu
sûr, car ils seront utilisés dans XL Deploy .

b. Configuration des Environnements et Robots

Assurez-vous que les robots UiPath sont correctement configurés dans l’Orchestrator et

associés aux environnements appropriés (par exemple, Production , Preprod ).

1.​ Accédez à Tenants > Environments .

2.​ Associez les robots à l’environnement cible où les processus seront exécutés.

2. Configuration de XL Deploy
XL Deploy agit comme l’intermédiaire entre Jenkins et l’Orchestrator UiPath. Il doit être

configuré pour utiliser la CLI UiPath et interagir avec l’Orchestrator.

a. Installation de la CLI UiPath sur XL Deploy

1.​ Installez la CLI UiPath ([Link]) sur le serveur où XL Deploy est hébergé.
2.​ Installez également .NET Desktop Runtime 6.0.7 (ou la version requise) sur ce
serveur.

b. Configuration des Credentials

1.​ Dans XL Deploy, configurez les credentials pour se connecter à l’Orchestrator :
●​ Stockez le Client ID et le Client Secret générés dans l’Orchestrator.
●​ Configurez l’URL de l’Orchestrator (par exemple, [Link]
ou [Link]
2.​ Testez la connexion en exécutant une commande CLI UiPath manuellement depuis
XL Deploy :
3.​
4.​ [Link] login --url [Link] --tenant
YourTenant --client-id YourClientId --client-secret
YourClientSecret

c. Création d’un Plugin ou Script pour XL Deploy

Si XL Deploy ne prend pas nativement en charge la CLI UiPath, vous pouvez créer un script

ou un plugin personnalisé pour exécuter les commandes CLI UiPath.

Exemple de script PowerShell pour déployer un package :

$packagePath = "C:\Path\To\[Link]"
$orchestratorUrl = "[Link]
$tenant = "YourTenant"
$clientId = "YourClientId"
$clientSecret = "YourClientSecret"

.\[Link] deploy --package $packagePath --url $orchestratorUrl

--tenant $tenant --client-id $clientId --client-secret
$clientSecret
Intégrez ce script dans XL Deploy pour automatiser le déploiement.

3. Configuration de XL Release
XL Release orchestre le flux de travail global, y compris les tâches effectuées par Jenkins et

XL Deploy.

a. Création d’un Template de Release

1.​ Dans XL Release, créez un template de release qui inclut les phases suivantes :
●​ Phase Jenkins : Déclenche le pipeline Jenkins pour générer le package
NuGet.
●​ Phase XL Deploy : Appelle XL Deploy pour déployer le package sur
l’Orchestrator UiPath.
●​ Phase Post-Déploiement : Exécute les tests ou jobs post-déploiement.
2.​ Configurez les dépendances entre les phases pour garantir que chaque étape est
exécutée dans l’ordre correct.

b. Intégration avec XL Deploy

Configurez XL Release pour appeler XL Deploy lors de la phase de déploiement. Utilisez les

informations suivantes :

●​ L’ID du package généré par Jenkins.

●​ Les credentials de l’Orchestrator stockés dans XL Deploy.

4. Validation Globale
Pour valider que tout fonctionne correctement :

1.​ Lancez un pipeline Jenkins pour générer un package NuGet.

2.​ Vérifiez que le package est transmis à XL Release.
3.​ Assurez-vous que XL Deploy déploie le package sur l’Orchestrator UiPath.
 4.​ Supervisez l’exécution des processus dans l’Orchestrator pour confirmer que tout
s’est déroulé comme prévu.

5. Conclusion
Dans une architecture Jenkins → XL Release → XL Deploy → Orchestrator UiPath , voici

les points clés à retenir :

1.​ Orchestrator UiPath : Déclarez une application externe et configurez les

robots/environnements.
2.​ XL Deploy : Installez la CLI UiPath et configurez les credentials pour interagir avec
l’Orchestrator.
3.​ XL Release : Orchestrez le flux de travail global en intégrant Jenkins et XL Deploy.
Cette configuration garantit une automatisation fluide et sécurisée de vos processus UiPath

dans un pipeline complexe.

Si vous avez besoin d’aide supplémentaire pour une étape spécifique, n’hésitez pas à

demander ! 😊
il me semble que la cli est juste utilisé pour les build des nupkg

Vous avez raison de souligner que l'une des utilisations principales de la CLI UiPath est pour

générer des packages NuGet (.nupkg) à partir de projets UiPath Studio. Cependant, la CLI

UiPath n'est pas limitée uniquement à cette fonctionnalité. Elle offre également d'autres

fonctionnalités importantes dans le cadre de l'automatisation du cycle de vie des processus

UiPath

. Voici une clarification :

1. Utilisation principale : Packaging des projets UiPath

La CLI UiPath est couramment utilisée pour générer des packages NuGet à partir de projets

UiPath Studio. Cette étape est essentielle pour préparer les processus automatisés avant

leur déploiement sur l’Orchestrator.

Commande pack
●​ La commande pack permet de convertir un projet UiPath Studio en un package
NuGet (.nupkg) prêt à être déployé.
 ●​ Exemple :
●​
●​ [Link] pack --project-path "C:\Path\To\YourProject"
--output-path "C:\Output"
●​ Cette commande crée un fichier .nupkg qui peut ensuite être déployé sur
l’Orchestrator
●​ 4
●​ .

2. Autres utilisations de la CLI UiPath

En plus du packaging, la CLI UiPath prend en charge plusieurs autres tâches clés dans le

cycle de vie des automatisations

a. Déploiement sur l’Orchestrator

●​ La CLI peut être utilisée pour déployer les packages NuGet générés sur
l’Orchestrator UiPath.
●​ Exemple :
●​
●​ [Link] deploy --package "C:\Path\To\[Link]"
--url [Link] --tenant YourTenant
--client-id YourClientId --client-secret YourClientSecret

b. Exécution de tests automatisés

●​ La CLI permet également d'exécuter des tests automatisés via UiPath Test Suite.
●​ Exemple :
●​
●​ [Link] run test --process-name YourProcessName --url
[Link] --tenant YourTenant --client-id
YourClientId --client-secret YourClientSecret
●​ Cette fonctionnalité est particulièrement utile pour intégrer les tests dans un pipeline
CI/CD
●​ 5
●​ .

c. Gestion des versions

 ●​ La CLI peut être utilisée pour incrémenter automatiquement les numéros de version
lors du packaging ou du déploiement, garantissant ainsi une gestion cohérente des
versions.

3. Intégration dans un pipeline CI/CD

Dans un pipeline CI/CD comme celui que vous décrivez (Jenkins → XL Release → XL

Deploy), la CLI UiPath peut être utilisée à plusieurs étapes :

1.​ Build : Générer le package NuGet avec la commande pack.

2.​ Déploiement : Déployer le package sur l’Orchestrator avec la commande deploy.
3.​ Tests : Exécuter des tests automatisés avec la commande run test.

4. Conclusion
Bien que la CLI UiPath soit principalement utilisée pour générer des packages NuGet

(.nupkg) , elle offre également des fonctionnalités supplémentaires telles que le déploiement

sur l’Orchestrator et l’exécution de tests automatisés. Ces capacités en font un outil

polyvalent pour automatiser l’ensemble du cycle de vie des processus UiPath dans un

pipeline CI/CD

Si vous avez besoin de précisions supplémentaires sur une fonctionnalité spécifique,

n’hésitez pas à demander ! 😊

dans un systeme bancaire ou tout est normalisé, il est hors de question alors qu'un pipeline

est en place de deployer en parralele sans passer par les outils qui permettent de tracer

Vous avez tout à fait raison. Dans un système bancaire où la normalisation et la traçabilité

sont des exigences fondamentales, il est essentiel de s'assurer que tous les déploiements

suivent des processus stricts et passent par des outils qui permettent de tracer chaque

étape du cycle de vie des applications

1
. Cela garantit non seulement la conformité réglementaire, mais aussi une meilleure gestion

des risques, une transparence accrue et une capacité à auditer les activités en cas de

besoin.

Pourquoi la traçabilité est-elle cruciale dans un système

bancaire ?
1.​ Conformité réglementaire :
●​ Les institutions financières sont soumises à des régulations strictes (par
exemple, Bâle III, RGPD, etc.) qui exigent une traçabilité complète des
changements apportés aux systèmes informatiques
●​ 1
●​ .
●​ Toute activité de déploiement doit être documentée pour prouver qu'elle
respecte les normes en vigueur.
2.​ Gestion des risques :
●​ Un déploiement non tracé peut introduire des vulnérabilités ou des erreurs
dans le système, ce qui pourrait avoir des conséquences graves sur la
stabilité financière et la réputation de l'institution
●​ 3
●​ .
3.​ Auditabilité :
●​ En cas d'incident ou de contrôle externe, il est impératif de pouvoir fournir une
vue claire et détaillée de toutes les actions effectuées, y compris les
déploiements.
4.​ Transparence et responsabilité :
●​ La traçabilité permet d'identifier qui a effectué une action, quand elle a été
réalisée et pourquoi elle était nécessaire. Cela renforce la responsabilité des
équipes techniques
●​ 7
●​ .

Comment intégrer la traçabilité dans un pipeline CI/CD

bancaire ?
Dans un environnement bancaire, les pipelines CI/CD doivent être conçus pour garantir une

traçabilité totale. Voici quelques bonnes pratiques :

1. Utiliser des outils de gestion des versions
●​ Stockez tous les artefacts générés (par exemple, les packages NuGet) dans un
référentiel centralisé comme JFrog Artifactory ou Nexus Repository .
●​ Chaque version doit être associée à des métadonnées détaillées, telles que l'auteur,
la date de création et le numéro de build.

2. Passer par des outils de déploiement standardisés

●​ Utilisez des outils comme XL Deploy , Octopus Deploy ou Azure DevOps pour
orchestrer les déploiements. Ces outils permettent de tracer chaque étape du
processus, de la génération du package à son déploiement en production
●​ 2
●​ .

3. Journalisation et audit
●​ Configurez des logs détaillés pour chaque étape du pipeline. Par exemple :
●​ Qui a déclenché le pipeline ?
●​ Quel package a été généré et déployé ?
●​ Quels tests ont été exécutés et quelles étaient les résultats ?
●​ Stockez ces logs dans un système centralisé comme ELK Stack (Elasticsearch,
Logstash, Kibana) ou Splunk pour faciliter les audits futurs.

4. Intégration avec des outils de gestion des incidents

●​ Connectez votre pipeline à des outils de gestion des incidents comme ServiceNow
ou Jira . Cela permet de créer automatiquement des tickets pour chaque
déploiement, facilitant ainsi le suivi et la résolution des problèmes.

5. Validation manuelle ou semi-automatique

●​ Dans un environnement bancaire, il est souvent nécessaire d'introduire des étapes
de validation manuelle avant de passer à l'étape suivante (par exemple, entre les
environnements de préproduction et de production).
●​ Ces validations doivent être enregistrées et associées à des approbations explicites.

Exemple : Pipeline CI/CD avec traçabilité dans un

contexte bancaire
Voici un exemple typique d'un pipeline CI/CD dans un système bancaire :

1.​ Phase de Build :

●​ Génération du package NuGet via la CLI UiPath.
●​ Stockage du package dans un référentiel centralisé avec des métadonnées
détaillées.
2.​ Phase de Test :
 ●​ Exécution des tests automatisés et enregistrement des résultats dans un outil
de reporting comme SonarQube ou Allure .
3.​ Phase de Déploiement :
●​ Utilisation d'un outil comme XL Deploy pour déployer le package sur
l’Orchestrator UiPath.
●​ Création d'un ticket dans ServiceNow pour documenter le déploiement.
4.​ Phase de Validation :
●​ Approbation manuelle par un responsable avant le passage en production.
●​ Enregistrement de l'approbation dans le système.
5.​ Phase de Surveillance :
●​ Supervision post-déploiement via des outils comme Dynatrace ou
AppDynamics pour détecter rapidement toute anomalie.

Conclusion
Dans un système bancaire, il est impératif que tous les déploiements passent par des outils

standardisés qui garantissent une traçabilité complète. Cela inclut l'utilisation de pipelines

CI/CD bien structurés, des référentiels centralisés pour les artefacts, des logs détaillés et

des mécanismes d'audit robustes

. En suivant ces bonnes pratiques, vous pouvez assurer la conformité réglementaire,

minimiser les risques et maintenir un haut niveau de transparence dans vos processus

Si vous avez besoin d'aide pour configurer un pipeline spécifique ou intégrer des outils de

traçabilité, n'hésitez pas à demander ! 😊

Voici un cahier des charges actualisé intégrant la problématique de coexistence de versions
de .NET Desktop Runtime sur votre serveur Jenkins :

●​ Contexte et objectifs
○​ Automatiser le cycle de vie des projets UiPath (packaging, déploiement,
tests) via la CLI UiPath.
○​ Intégrer cette automatisation dans un pipeline CI/CD Jenkins afin d’améliorer
la rapidité et la fiabilité des déploiements.
●​ Environnement technique
○​ Serveur Jenkins
■​ Version recommandée : Jenkins 2.x ou supérieure.
■​ Agents de build sous Windows (pour utiliser la version
[Link]).
 ○​ Prérequis logiciels
■​ Installation de .NET Desktop Runtime requis par la CLI (exemple :
.NET 6.0.7 Desktop Runtime).
■​ Vérifier la présence d’autres versions de .NET Desktop Runtime déjà
utilisées par certains plugins Jenkins.
○​ Accès et authentifications
■​ Accès au dépôt Bitbucket pour le code source.
■​ Droits sur l’Orchestrator UiPath pour le déploiement, la publication et
l’exécution de tests.
■​ Gestion sécurisée des credentials via le Jenkins Credentials Plugin.
●​ Fonctionnalités attendues
○​ Packaging automatisé
■​ Exécution de la commande « pack » pour convertir un projet UiPath
Studio en package NuGet.
○​ Déploiement sur Orchestrator
■​ Exécution de la commande « deploy » pour envoyer le package sur
Orchestrator.
○​ Exécution de tests et déclenchement de jobs
■​ Lancement de tests automatisés ou de jobs post-déploiement via la
commande « run test » ou équivalent.
○​ Gestion de version
■​ Incrémentation automatique du numéro de version lors du
packaging/déploiement.
○​ Reporting et logs
■​ Capture et stockage des logs d’exécution pour suivi et traçabilité.
■​ Notifications (email, Slack…) en cas d’échec ou de succès.
●​ Gestion des conflits de versions .NET Desktop Runtime
○​ Côté système Windows
■​ Windows permet l’installation côte à côte de plusieurs versions de
.NET Desktop Runtime.
■​ Assurez-vous que la version spécifique requise par la CLI (par
exemple, .NET 6.0.7) est installée parallèlement à l’autre version déjà
présente.
○​ Isolation et tests de compatibilité
■​ Vérifiez que l’exécutable de la CLI ([Link]) utilise bien la version de
.NET pour laquelle il a été compilé.
■​ Testez les plugins Jenkins existants afin de vous assurer qu’ils
continuent à fonctionner avec leur version de .NET.
■​ Si des conflits apparaissent ou si les plugins sensibles posent
problème, envisagez l’utilisation d’un agent Jenkins dédié ou d’un
conteneur pour isoler l’environnement de la CLI.
○​ Documentation et support
■​ Consulter la documentation de chaque plugin Jenkins pour confirmer
leurs prérequis .NET.
■​ Mettre en place une procédure de rollback ou de test de
non-régression afin de valider qu’aucun service n’est impacté par
l’installation parallèle.
●​ Étapes d’implémentation
 ○​ Installation de la CLI sur l’agent Jenkins
■​ Télécharger la CLI UiPath depuis le flux public (exemple pour
[Link] version 23.10.8753.32995 :​
[Link]
cial/NuGet/[Link]/versions/23.10.8753.32995).
■​ Extraire le package et placer l’exécutable dans un répertoire dédié sur
l’agent Jenkins.
■​ Vérifier l’exécution via PowerShell (exemple : .\[Link] --version).
○​ Configuration du pipeline Jenkins
■​ Créer un job ou pipeline dédié qui intègre les étapes de packaging,
déploiement et tests.
■​ Ajouter une étape pour définir les variables d’environnement et
spécifier le chemin de l’exécutable de la CLI.
■​ Configurer les scripts pour appeler les commandes de la CLI (pack,
deploy, runtest) en gérant les retours et erreurs.
○​ Gestion de l’environnement .NET
■​ Installer la version requise (.NET 6.0.7 Desktop Runtime) en parallèle
de l’autre version.
■​ Tester que l’agent Jenkins peut lancer la CLI sans interférer avec les
autres plugins qui utilisent une version différente.
○​ Intégration et tests
■​ Exécuter des tests d’intégration sur un environnement de
pré-production pour valider la coexistence des versions de .NET et le
bon fonctionnement de la CLI.
■​ Vérifier les logs et corriger les éventuels problèmes de compatibilité.
●​ Sécurité et gestion des accès
○​ Stocker les credentials et secrets de manière sécurisée avec le Jenkins
Credentials Plugin.
○​ Limiter les accès aux scripts et exécutables via des politiques de sécurité sur
l’agent.
●​ Documentation et formation
○​ Rédiger un guide détaillé pour l’installation, la configuration et la gestion des
versions multiples de .NET.
○​ Organiser une session de formation pour l’équipe DevOps sur le déploiement
et la maintenance de la CLI dans l’environnement Jenkins.
●​ Maintenance et support
○​ Planifier des mises à jour régulières de la CLI et des composants .NET.
○​ Mettre en place un monitoring des jobs Jenkins pour détecter rapidement
toute anomalie liée à la coexistence des versions de .NET.
○​ Prévoir des procédures de rollback en cas de conflits non résolus.

En résumé, ce cahier des charges vous offre une feuille de route pour installer la CLI UiPath
sur Jenkins tout en prenant en compte la coexistence de différentes versions de .NET
Desktop Runtime. Bien que Windows permette une installation côte à côte, des tests
approfondis et éventuellement une isolation par agent ou conteneur sont recommandés pour
garantir la compatibilité avec l’ensemble des plugins Jenkins déjà en place.
Voici un cahier des charges actualisé intégrant la problématique de coexistence de versions
de .NET Desktop Runtime sur votre serveur Jenkins :

●​ Contexte et objectifs
○​ Automatiser le cycle de vie des projets UiPath (packaging, déploiement,
tests) via la CLI UiPath.
○​ Intégrer cette automatisation dans un pipeline CI/CD Jenkins afin d’améliorer
la rapidité et la fiabilité des déploiements.
●​ Environnement technique
○​ Serveur Jenkins
■​ Version recommandée : Jenkins 2.x ou supérieure.
■​ Agents de build sous Windows (pour utiliser la version
[Link]).
○​ Prérequis logiciels
■​ Installation de .NET Desktop Runtime requis par la CLI (exemple :
.NET 6.0.7 Desktop Runtime).
■​ Vérifier la présence d’autres versions de .NET Desktop Runtime déjà
utilisées par certains plugins Jenkins.
○​ Accès et authentifications
■​ Accès au dépôt Bitbucket pour le code source.
■​ Droits sur l’Orchestrator UiPath pour le déploiement, la publication et
l’exécution de tests.
■​ Gestion sécurisée des credentials via le Jenkins Credentials Plugin.
●​ Fonctionnalités attendues
○​ Packaging automatisé
■​ Exécution de la commande « pack » pour convertir un projet UiPath
Studio en package NuGet.
○​ Déploiement sur Orchestrator
■​ Exécution de la commande « deploy » pour envoyer le package sur
Orchestrator.
○​ Exécution de tests et déclenchement de jobs
■​ Lancement de tests automatisés ou de jobs post-déploiement via la
commande « run test » ou équivalent.
○​ Gestion de version
■​ Incrémentation automatique du numéro de version lors du
packaging/déploiement.
○​ Reporting et logs
■​ Capture et stockage des logs d’exécution pour suivi et traçabilité.
■​ Notifications (email, Slack…) en cas d’échec ou de succès.
●​ Gestion des conflits de versions .NET Desktop Runtime
○​ Côté système Windows
■​ Windows permet l’installation côte à côte de plusieurs versions de
.NET Desktop Runtime.
■​ Assurez-vous que la version spécifique requise par la CLI (par
exemple, .NET 6.0.7) est installée parallèlement à l’autre version déjà
présente.
○​ Isolation et tests de compatibilité
 ■​ Vérifiez que l’exécutable de la CLI ([Link]) utilise bien la version de
.NET pour laquelle il a été compilé.
■​ Testez les plugins Jenkins existants afin de vous assurer qu’ils
continuent à fonctionner avec leur version de .NET.
■​ Si des conflits apparaissent ou si les plugins sensibles posent
problème, envisagez l’utilisation d’un agent Jenkins dédié ou d’un
conteneur pour isoler l’environnement de la CLI.
○​ Documentation et support
■​ Consulter la documentation de chaque plugin Jenkins pour confirmer
leurs prérequis .NET.
■​ Mettre en place une procédure de rollback ou de test de
non-régression afin de valider qu’aucun service n’est impacté par
l’installation parallèle.
●​ Étapes d’implémentation
○​ Installation de la CLI sur l’agent Jenkins
■​ Télécharger la CLI UiPath depuis le flux public (exemple pour
[Link] version 23.10.8753.32995 :​
[Link]
cial/NuGet/[Link]/versions/23.10.8753.32995).
■​ Extraire le package et placer l’exécutable dans un répertoire dédié sur
l’agent Jenkins.
■​ Vérifier l’exécution via PowerShell (exemple : .\[Link] --version).
○​ Configuration du pipeline Jenkins
■​ Créer un job ou pipeline dédié qui intègre les étapes de packaging,
déploiement et tests.
■​ Ajouter une étape pour définir les variables d’environnement et
spécifier le chemin de l’exécutable de la CLI.
■​ Configurer les scripts pour appeler les commandes de la CLI (pack,
deploy, runtest) en gérant les retours et erreurs.
○​ Gestion de l’environnement .NET
■​ Installer la version requise (.NET 6.0.7 Desktop Runtime) en parallèle
de l’autre version.
■​ Tester que l’agent Jenkins peut lancer la CLI sans interférer avec les
autres plugins qui utilisent une version différente.
○​ Intégration et tests
■​ Exécuter des tests d’intégration sur un environnement de
pré-production pour valider la coexistence des versions de .NET et le
bon fonctionnement de la CLI.
■​ Vérifier les logs et corriger les éventuels problèmes de compatibilité.
●​ Sécurité et gestion des accès
○​ Stocker les credentials et secrets de manière sécurisée avec le Jenkins
Credentials Plugin.
○​ Limiter les accès aux scripts et exécutables via des politiques de sécurité sur
l’agent.
●​ Documentation et formation
○​ Rédiger un guide détaillé pour l’installation, la configuration et la gestion des
versions multiples de .NET.
 ○​ Organiser une session de formation pour l’équipe DevOps sur le déploiement
et la maintenance de la CLI dans l’environnement Jenkins.
●​ Maintenance et support
○​ Planifier des mises à jour régulières de la CLI et des composants .NET.
○​ Mettre en place un monitoring des jobs Jenkins pour détecter rapidement
toute anomalie liée à la coexistence des versions de .NET.
○​ Prévoir des procédures de rollback en cas de conflits non résolus.

En résumé, ce cahier des charges vous offre une feuille de route pour installer la CLI UiPath
sur Jenkins tout en prenant en compte la coexistence de différentes versions de .NET
Desktop Runtime. Bien que Windows permette une installation côte à côte, des tests
approfondis et éventuellement une isolation par agent ou conteneur sont recommandés pour
garantir la compatibilité avec l’ensemble des plugins Jenkins déjà en place.

Vous avez dit :

et coté orchestrator que faut il faire, sachant que la cli uipath sera installé sur les serveur
Jenkins pour les build en nupkg
Raisonnement terminé pendant 31 secondes

Voici une liste détaillée des actions à réaliser côté Orchestrator pour que la CLI UiPath,
installée sur votre serveur Jenkins, puisse fonctionner correctement :

●​ Configuration d’accès et d’authentification

○​ Créez une application externe dans Orchestrator pour authentifier les
appels effectués par la CLI.
○​ Définissez les scopes et rôles appropriés (par exemple, le rôle
[Link]) afin de limiter l’accès aux actions nécessaires (déploiement,
exécution de tests, etc.).
○​ Fournissez les identifiants (client id et client secret) générés par cette
application externe à votre pipeline Jenkins.
●​ Configuration du flux de packages
○​ Vérifiez que le feed NuGet dans Orchestrator est correctement configuré et
accessible pour recevoir les packages déployés.
○​ Assurez-vous que l’Orchestrator est configuré pour prendre en charge le
versioning et la signature des packages si nécessaire.
●​ Définition des environnements de déploiement
○​ Organisez les dossiers dans Orchestrator de manière à isoler les
déploiements issus de votre pipeline CI/CD (par exemple, un dossier dédié
aux builds automatisés).
○​ Configurez les environnements de runtime pour que les packages déployés
puissent être exécutés et testés de manière isolée.
●​ Paramètres réseau et sécurité
○​ Assurez-vous que votre serveur Jenkins (ou l’agent Jenkins) peut
communiquer avec Orchestrator sans problème (configuration des
firewalls, proxy, etc.).
○​ Mettez en place des mesures de sécurité pour protéger les échanges entre
Jenkins et Orchestrator, notamment via HTTPS.
 ●​ Suivi, reporting et logs
○​ Configurez la surveillance des déploiements et des jobs sur Orchestrator
pour suivre en temps réel l’état des exécutions et détecter d’éventuelles
erreurs.
○​ Mettez en place des notifications (email, Slack, etc.) pour être alerté en cas
de succès ou d’échec des déploiements.
●​ Compatibilité et mises à jour
○​ Vérifiez que la version de l’Orchestrator (2022) est compatible avec les
fonctionnalités de la CLI que vous comptez utiliser.
○​ Documentez et testez les interactions entre Jenkins (via la CLI) et
Orchestrator afin de vous assurer qu’aucune configuration supplémentaire
n’est requise en cas de mise à jour future.
●​ Documentation et formation
○​ Rédigez une documentation détaillée sur la configuration d’Orchestrator pour
le déploiement via CI/CD (création de l’application externe, gestion des rôles,
configuration du feed NuGet, etc.).
○​ Organisez une session de formation pour les équipes concernées afin de
garantir une bonne compréhension des processus et des procédures de
déploiement automatisé.

Ces actions côté Orchestrator garantissent que la CLI, déployée via votre pipeline Jenkins,
pourra interagir correctement pour publier et déployer les packages NuGet, lancer les tests
et gérer les exécutions de jobs, tout en assurant la sécurité et la traçabilité des opérations.

Vous avez dit :

meme si on utilise la cli uipath uniquement pour les builds, il faut alors creer una pplication
externe coté orchestrator ? pourquoi?
Raisonnement terminé pendant 12 secondes

●​ Sécurité et contrôle d'accès

○​ Même si la CLI est utilisée uniquement pour les builds, elle interagit avec
Orchestrator (par exemple, pour publier ou récupérer des packages NuGet).
○​ Créer une application externe permet d’authentifier et de contrôler
précisément ces interactions, limitant ainsi l’accès aux seules fonctionnalités
nécessaires.
●​ Bonne pratique et conformité
○​ UiPath recommande l’utilisation d’une application externe pour toutes les
communications automatisées, afin de garantir la traçabilité et la gestion
sécurisée des accès.
○​ Cela permet également de préparer le terrain pour d’éventuelles évolutions
futures, comme le déploiement ou l’exécution de tests, sans devoir
reconfigurer la méthode d’authentification.
●​ Gestion des permissions
○​ En configurant une application externe, vous pouvez définir un scope
spécifique (ex. : [Link]) qui restreint les droits d’accès aux seules
 opérations de build et publication, évitant ainsi d’exposer d’autres
fonctionnalités sensibles d’Orchestrator.

En résumé, même si la CLI est utilisée uniquement pour les builds, la création d’une
application externe côté Orchestrator est nécessaire pour assurer une authentification
sécurisée, contrôler les accès et respecter les bonnes pratiques de sécurité recommandées
par UiPath.

Vous avez dit :

je ne comprends pas! le build est une espece de compilation, pourquoi la cli devrait
communiquer avec l'orchestrator
Raisonner sur la nécessité de la CLI UiPath avec Orchestrator pendant 8 secondes

●​ Packaging vs. Compilation

○​ Dans UiPath, le "build" ne se limite pas à une compilation classique : il s'agit
de créer un package NuGet à partir d'un projet Studio. Ce package est
ensuite destiné à être déployé sur Orchestrator.
●​ Rôle de la CLI dans le processus de build
○​ La CLI est utilisée pour automatiser la transformation du projet en package, et
souvent, pour publier ce package sur Orchestrator.
○​ Même si vous n'exécutez que l'étape de packaging, le processus prépare le
terrain pour le déploiement et la validation via Orchestrator.
●​ Communication avec Orchestrator
○​ Pour publier le package, la CLI doit établir une connexion sécurisée avec
Orchestrator, ce qui implique l'authentification via une application externe.
○​ Cette communication assure que seules les actions autorisées (comme la
mise en ligne du package) sont effectuées, renforçant ainsi la sécurité et la
traçabilité.

En résumé, même si le build ressemble à une compilation, il intègre la phase de packaging

et de publication, nécessitant ainsi une interaction avec Orchestrator pour finaliser le
déploiement de vos automatisations.

Vous avez dit :

mais le deploiement ne se fait pas sur le jenkins, il se fait en finalité du pipeline via xldeploy?
donc ce que tu appele publier c'est recuperer les divers librairie
Raisonné sur l'utilisation de la CLI UiPath avec Jenkins et Orchestrator pendant 11
secondes

●​ Séparation des responsabilités dans le pipeline

○​ Dans votre pipeline, le rôle de Jenkins (avec la CLI UiPath) est de générer
(packager) et "publier" le package NuGet, c'est-à-dire de le rendre disponible
dans un dépôt ou feed.
○​ Le déploiement final sur Orchestrator est ensuite géré par XLDeploy, qui
récupère ce package pour effectuer le déploiement.
 ●​ Que signifie "publier" dans ce contexte ?
○​ "Publier" ne signifie pas déployer directement sur Orchestrator, mais plutôt
mettre à disposition les librairies et packages créés par le build dans un
repository ou feed accessible aux outils de déploiement.
○​ Cela permet à XLDeploy de récupérer le package et de lancer le déploiement
sur Orchestrator selon la configuration définie.
●​ Avantages de cette approche
○​ Modularité : Séparation claire entre la phase de build (gérée par Jenkins et
la CLI) et la phase de déploiement (gérée par XLDeploy).
○​ Flexibilité : Chaque outil se concentre sur sa tâche spécifique, facilitant la
maintenance et les mises à jour indépendantes.
○​ Traçabilité : Le package publié dans le feed est une source unique de vérité
pour le déploiement, garantissant que la version déployée correspond
exactement au build réalisé.

En résumé, même si le déploiement final est assuré par XLDeploy, la commande "publier"
via la CLI UiPath dans Jenkins consiste à rendre le package (et les librairies) disponibles
pour que XLDeploy puisse les récupérer et déployer sur Orchestrator.

Vous avez dit :

deteille moi ce qui se passe entre l'orchestraor et la cli uipath lors d'un build sur le serveur
jenkins
Raison sur l'interaction entre Orchestrator et la CLI UiPath lors d'un build sur Jenkins
pendant 13 secondes

●​ Déclenchement du build sur Jenkins

○​ Jenkins détecte une modification (via Bitbucket, par exemple) et déclenche le
pipeline CI/CD.
○​ Le job Jenkins lance un script PowerShell (ou un autre type de script) qui
appelle la CLI UiPath installée sur l’agent Jenkins.
●​ Étape de packaging (build)
○​ La commande de packaging (ex. : [Link] pack --project
"chemin\vers\projet" --output "chemin\vers\output") est
exécutée.
○​ La CLI lit le projet UiPath et génère un package NuGet contenant
l’automatisation et ses dépendances.
●​ Authentification et préparation à la publication
○​ Si la CLI est configurée pour publier le package, elle doit établir une
connexion sécurisée avec Orchestrator.
○​ Elle utilise un mécanisme d’authentification basé sur une application
externe configurée sur Orchestrator, avec un client id, un client secret et un
scope défini (par exemple, [Link]).
○​ La CLI envoie une requête d’authentification à Orchestrator pour obtenir un
token d’accès.
●​ Communication avec Orchestrator pour la publication
 ○​ Avec le token obtenu, la CLI envoie une requête HTTP vers l’API
d’Orchestrator pour publier le package NuGet.
○​ Orchestrator reçoit la requête, vérifie l’authentification, et valide la structure et
la version du package.
○​ Le package est ensuite enregistré dans le feed NuGet d’Orchestrator, rendant
les librairies disponibles pour les étapes ultérieures (par exemple, pour
XLDeploy).
●​ Retour d’information et traçabilité
○​ Orchestrator répond à la CLI avec un statut indiquant le succès ou l’échec de
la publication.
○​ La CLI transmet cette réponse à Jenkins, qui consigne le résultat dans les
logs du pipeline et, éventuellement, déclenche des notifications (email, Slack,
etc.).
●​ Utilisation ultérieure du package
○​ Bien que le déploiement final soit géré par XLDeploy (qui récupérera ce
package depuis le feed), la communication entre la CLI et Orchestrator
assure que le package est correctement construit, validé et accessible.
○​ Cela garantit la traçabilité et la sécurité du processus, même si la CLI
n’exécute que l’étape de build et de publication.

En résumé, lors d’un build sur le serveur Jenkins, la CLI UiPath effectue le packaging du
projet, se connecte à Orchestrator pour authentifier et publier le package NuGet, puis reçoit
un retour sur le succès de cette opération, ce qui permet ensuite à d’autres outils comme
XLDeploy de récupérer le package pour le déploiement final.

Vous avez dit :

ok mais l'application externe pour la communication entre la cli uipath et l'orchestrator, doit
etre definie sur chaque tenant ou uniquement sur le Host
Raisonner sur la configuration de l'application externe UiPath pendant 15 secondes

●​ Création au niveau du tenant

○​ L'application externe est définie au sein d'un tenant spécifique dans
Orchestrator, car elle gère l'authentification et les permissions pour les
ressources de ce tenant.
○​ Si votre pipeline CI/CD ne cible qu'un seul tenant, une seule application
externe dans ce tenant suffit.
●​ Cas multi-tenant
○​ Si votre environnement Orchestrator est configuré en mode multi-tenant et
que votre pipeline doit interagir avec plusieurs tenants, il faudra créer une
application externe pour chaque tenant concerné.
○​ Cela permet d'attribuer des permissions spécifiques à chaque tenant et de
limiter l'accès aux ressources nécessaires.
●​ Pourquoi cette configuration ?
○​ Cela assure une sécurité renforcée et une gestion granulaire des accès,
en restreignant les actions aux seules ressources du tenant ciblé.
 ○​ La création d'une application externe dans chaque tenant permet de suivre
les bonnes pratiques recommandées par UiPath pour l'authentification des
applications automatisées.

En résumé, l'application externe doit être définie au niveau du tenant cible. Pour un
environnement mono-tenant, une seule instance suffit, tandis qu'en multi-tenant, il faut
configurer une application externe dans chaque tenant pour garantir une gestion sécurisée
et adaptée des accès.

Vous avez dit :

pourtant dans le build du package il n'y a pas la notion de tenant, cette notion est noté lors
de la montée d'un nouvelle version du template de deploiement que XLrelease
Raisonner sur la gestion des tenants avec la CLI UiPath pendant 8 secondes

●​ Phase de build vs. phase de déploiement

○​ La création du package (build) avec la CLI consiste à transformer le projet en
un package NuGet et ne nécessite pas de spécifier de tenant.
○​ Le tenant entre en jeu lors de la publication et du déploiement du package,
c'est-à-dire quand on veut que le package soit utilisé dans un environnement
spécifique sur Orchestrator.
●​ Rôle de l'application externe
○​ L'application externe est utilisée pour authentifier et sécuriser la
communication entre la CLI et Orchestrator lors de la publication ou du
déploiement du package.
○​ Même si la phase de build est indépendante du tenant, publier le package
dans le feed d'Orchestrator et lancer des déploiements requiert le contexte du
tenant (via l'application externe).
●​ Interaction avec XLRelease
○​ Dans votre chaîne CI/CD, XLRelease prend en charge le déploiement final, et
le template de déploiement définit la cible tenant.
○​ Ainsi, lors de la montée d'une nouvelle version avec XLRelease, la notion de
tenant est intégrée pour diriger le déploiement vers le bon environnement.
●​ Conclusion
○​ La CLI peut construire le package sans référence au tenant, mais pour que
ce package soit exploité (publié et déployé) dans Orchestrator, il est
nécessaire d'avoir une application externe configurée dans le tenant ciblé.
○​ Cette séparation permet de conserver une flexibilité dans le processus de
build tout en assurant la sécurité et la précision lors du déploiement via
XLRelease.

Vous avez dit :

je ne remet pas en cause qu'il faille une application externe, ce qui me choque c'est qu'il
faille la definir sur chaque tenant alors que lors du build il n'y a pas la notion de tenant???
Raisonner sur la gestion de l'application externe et des tenants pendant 6 secondes
 ●​ Phase de build vs. phase de publication/déploiement
○​ Le build consiste uniquement à transformer votre projet en package NuGet,
sans référence à un tenant particulier.
○​ En revanche, la publication ou le déploiement du package sur Orchestrator
nécessite de connaître le contexte tenant, car Orchestrator organise ses
ressources par tenant.
●​ Rôle de l’application externe
○​ L’application externe sert à authentifier et à sécuriser les interactions entre la
CLI et Orchestrator lors de la publication ou du déploiement.
○​ Pour publier ou déployer un package dans un tenant spécifique, il faut que
l’application externe soit définie dans ce tenant, afin de fournir les
permissions et le contexte requis.
●​ Contexte multi-tenant vs. mono-tenant
○​ Dans un environnement mono-tenant, une seule application externe suffit
puisque tous les déploiements se font dans le même tenant.
○​ Dans un environnement multi-tenant, chaque tenant dispose de ses propres
ressources et de son propre feed NuGet, ce qui nécessite de configurer une
application externe par tenant pour assurer une sécurité et une isolation
appropriées.
●​ Pourquoi cette séparation ?
○​ Bien que le build soit une opération générique (tenant-agnostique), la
publication est intrinsèquement liée à un tenant précis, car c'est dans ce
contexte que le package sera utilisé et déployé.
○​ Cela permet également d’appliquer des politiques de sécurité spécifiques à
chaque tenant, garantissant que les accès automatisés sont limités aux
ressources de ce tenant.

En résumé, la nécessité de définir l’application externe sur chaque tenant ne concerne pas
la phase de build en elle-même, mais bien les étapes ultérieures de publication et de
déploiement qui nécessitent une identification précise du contexte tenant pour garantir la
sécurité et la gestion appropriée des ressources sur Orchestrator.

Vous avez dit :

reprend tes explication, car tu embrouille, comme je t'ai dis le deploiement est fait via
XLdeploy, et on "nutilise pas la cli, donc reprends tes explication en parlant uniquement de
publication, et expliques moi pourquoi il fgaut decrire l'application externe sur chaque tenant
Raisonnement terminé pendant 8 secondes

●​ Contexte de la publication
○​ La publication consiste à transférer les packages NuGet générés vers le feed
d’Orchestrator.
○​ Ce feed est structuré par tenant, chaque tenant gérant ses propres
ressources et configurations de sécurité.
●​ Rôle de l’application externe dans la publication
○​ Elle permet d’authentifier et d’autoriser la publication du package dans
Orchestrator.
 ○​ L’application externe fournit les identifiants (client id et client secret)
nécessaires pour valider la demande de publication.
●​ Pourquoi définir l’application externe sur chaque tenant ?
○​ Isolation et sécurité :
■​ Chaque tenant est isolé avec ses propres règles de sécurité.
■​ Une application externe définie dans un tenant garantit que les actions
de publication sont restreintes à ce tenant uniquement.
○​ Conformité aux politiques de sécurité :
■​ Les politiques d’accès et de gestion des ressources sont spécifiques à
chaque tenant.
■​ Pour respecter ces politiques, il est indispensable d’avoir une
application externe propre à chaque tenant.
○​ Utilisation par XLDeploy :
■​ Même si XLDeploy réalise le déploiement final, il doit récupérer le
package publié dans le feed du tenant ciblé.
■​ Pour que XLDeploy puisse accéder aux packages de manière
sécurisée, l’authentification via l’application externe doit être
configurée dans le tenant concerné.

En résumé, même si le build ne fait pas intervenir la notion de tenant, la phase de

publication exige une authentification tenant-spécifique. C’est pourquoi, dans un
environnement multi-tenant, il est nécessaire de définir une application externe dans chaque
tenant pour sécuriser et isoler les opérations de publication.

Vous avez dit :

"En résumé, même si le build ne fait pas intervenir la notion de tenant, la phase de
publication exige une authentification tenant-spécifique. C’est pourquoi, dans un
environnement multi-tenant, il est nécessaire de définir une application externe dans chaque
tenant pour sécuriser et isoler les opérations de publication." il y a des bizarreie qui ne sont
pas logique et je ne comprends pas, selon toi, il faut decrire une app exte sur Tenant1,
tenant2....etc... or lorsque l'on effectue le build, il y a AUCUNE nOTION de tenant alors
pourqupoi la publication irai sur tenant1, tenant2 ...etc ... puisque cela est specifié
NULLEPART
Raisonner sur nécessité de l'application externe par tenant pendant 8 secondes

●​ Phase de build vs. phase de publication

○​ Lors de la phase de build, vous générez un package NuGet à partir de votre
projet UiPath.
○​ Cette étape est « tenant-agnostique » : elle ne nécessite pas de préciser de
tenant, car elle se contente de compiler le package.
●​ Publication du package
○​ La publication consiste à transférer ce package dans le feed NuGet
d’Orchestrator, afin qu’il soit disponible pour le déploiement.
○​ Ici, le contexte du tenant devient essentiel, car chaque tenant d’Orchestrator
possède son propre feed et ses règles de sécurité.
●​ Pourquoi définir une application externe dans chaque tenant ?
 ○​ Sécurité et authentification :
■​ Pour publier un package dans un tenant spécifique, il faut authentifier
l’opération avec des identifiants valides pour ce tenant.
■​ Une application externe configurée dans Tenant1, par exemple, fournit
des identifiants (client id et client secret) permettant à la publication de
s’effectuer de manière sécurisée dans Tenant1.
○​ Configuration de la publication :
■​ Même si le build est indépendant du tenant, le processus de
publication (qu’il soit déclenché via la CLI ou par XLDeploy) doit savoir
vers quel tenant envoyer le package.
■​ Dans votre pipeline ou dans la configuration de XLDeploy, vous
spécifiez la cible de publication (par exemple, Tenant1, Tenant2, etc.).
■​ Pour chaque cible, il faut utiliser l’application externe associée à ce
tenant pour authentifier la requête de publication.
●​ Synthèse
○​ Le package généré par le build n’intègre pas la notion de tenant.
○​ Lors de la publication, le pipeline ou l’outil de déploiement doit indiquer dans
quel tenant publier le package.
○​ Pour sécuriser cette opération, il est indispensable de définir une application
externe dans chaque tenant cible, afin que l’authentification et les
permissions soient correctement gérées.
○​ Ainsi, même si le build est tenant-agnostique, la publication se fait dans un
tenant spécifique, d’où la nécessité d’avoir une application externe configurée
pour chaque tenant concerné.

Ce mécanisme assure que chaque opération de publication est isolée et sécurisée selon le
contexte du tenant dans lequel elle est effectuée.

Vous avez dit :

donc il faut declarer une app exter, car la publication du package necessite de transferer le
package dans le Feed nugetr du tenant?
Raisonnement terminé pendant 4 secondes

●​ Oui, c'est exact.

○​ La publication du package consiste à transférer le package NuGet dans le
feed d'Orchestrator, lequel est spécifique à un tenant.
○​ Pour sécuriser et authentifier cette opération, il faut utiliser une application
externe configurée dans le tenant ciblé.
○​ Même si la phase de build ne spécifie pas de tenant, la publication doit
indiquer clairement dans quel tenant le package sera stocké, ce qui nécessite
les identifiants (client id et client secret) fournis par l'application externe.
○​ Ainsi, dans un environnement multi-tenant, chaque tenant de publication doit
avoir sa propre application externe pour garantir que le transfert vers le feed
NuGet se fasse de manière sécurisée et isolée.
Vous avez dit :
ok ce n'est pas lié au build mais a la publication
Razonné sur la notion de tenant et publication de package pendant quelques secondes

●​ Oui, c'est exactement ça.

○​ Le processus de build génère un package NuGet sans notion de tenant, ce
qui le rend indépendant du contexte tenant.
○​ En revanche, la publication consiste à transférer ce package dans le feed
NuGet d’Orchestrator, qui est propre à chaque tenant.
○​ Pour sécuriser cette publication et authentifier l’opération dans un tenant
spécifique, il est indispensable de déclarer une application externe dans ce
tenant.