Erreur Jenkins lors du clonage du référentiel distant 'Origin', noeud esclave
J'ai besoin d'aide ici, cela fait une semaine que je suis avec ce problème, je ne peux pas comprendre ce qui se passe. Je ne suis pas en mesure de cloner un dépôt Git à partir d'un nœud esclave (Jenkins). J'ai ajouté la clé ssh, hôte et esclave (j'ai déjà essayé de générer une seule clé et une pour chaque hôte virtuel et hôte).
Sur Jenkins:
- url: [email protected]: <repo>
- Informations d'identification: ici, j'ai essayé avec nom d'utilisateur/mot de passe, nom d'utilisateur avec fichier ssh, nom d'utilisateur avec clé ssh directement, et -none-.
Il ne semble pas qu'il y ait un problème d'authentification puisque je peux cloner le référentiel manuellement à partir de la console (esclave et hôte). Je peux aussi me connecter avec
ssh -T [email protected]
la clé ssh va bien, mais lorsque je construis, cela apparaît sur la console:
Construction à distance sur IE10Win7 dans l'espace de travail C:\Users\IEUser\Desktop\< dossier>
Essuyer l’espace de travail en premier.
Clonage du référentiel Git distant
Clonage du référentiel [email protected]: <repo> .git
git initi C:\Users\IEUser\Desktop\<dossier> # timeout = 10
ERREUR: erreur de clonage du référentiel distant 'Origin'
ERREUR: erreur de clonage du référentiel distant 'Origin'
Effectuer une tâche de construction postérieure ...
Est-ce que quelqu'un a une idée? J'espère que quelqu'un pourra me donner un indice, merci!
J'ai résolu ce problème en définissant le chemin de l'outil du nœud esclave, en sélectionnant git et en lui affectant
C:\Program Files (x86)\Git\bin\git.exe
Emplacement: Configurer le nœud - Emplacements des outils
J'ai récemment mis à jour plusieurs plugins jenkins et j'ai eu ce problème après les mises à jour. Revenir en arrière avec le plugin git n'a pas aidé, mais j'ai fait quelques autres choses pour le faire fonctionner. J'ai énuméré les trois ici, mais c'est probablement (2) qui a résolu le problème. Apparemment, l'exécutable git était réinitialisé. Ainsi, la configuration de l'exécutable git dans le projet spécifique était probablement tout ce qui était nécessaire . Cependant, les autres éléments pourraient également s'avérer utiles.
(1) Le git par défaut sur une installation jenkins linux pointe généralement vers/usr/lib ... Vous devez spécifier un GitForWindows distinct qui pointe vers la version Windows:
Manage Jenkins
Configure System
Under Git - Git Installations
Add Git -> Git
Give it a name to be referenced in projects
(mine is WindowsGit)
Set Path to Git Executable
(mine is "C:\Program Files (x86)\Git\bin\git.exe")
(for recent git the path is "C:\Program Files\Git\bin\git.exe")
(2) Configurez git sur le projet spécifique:
Select the project
Select Configure
Under Source Code Management - Git
Select Git Executable as configured in 1)
Set credentials or add new (ssh keys, etc)
(3) Mise à jour du service esclave jenkins pour qu'il s'exécute en tant qu'utilisateur spécifique:
Go to Windows Services on the slave -- StartMenu, type "services"
Select the Jenkins Slave service in the list on the right
Right-click and select "Properties" of the Jenkins Slave service
Select the "Log On" tab
Update the username and password used in manual tests
Domain login can be specificied with <DOMAIN>\<USERNAME>
Local logins just use <USERNAME>
OK to save and exit
Right-click again and select "Restart" to make the changes active.
J'ai trouvé une solution de contournement décent dans mon cas. La commande git clone hérite toujours de son propriétaire de processus, ce qui peut faire toute la différence, même si les deux propriétaires de Jenkins (SYSTEM) et de cmd (USER) semblent avoir les mêmes droits sur votre système. Toutes les autres configurations étaient identiques (clés, hôtes connus, version du client Git).
Donc, autant que je sache, l'appel de git clone à partir de cmd réussira car il appelle la télécommande en tant que USER, alors que git clone appelé depuis Jenkins peut être rejeté car il appelle la télécommande en tant que SYSTEM. Dans Services, où vous lancerez généralement Jenkins via l'interface graphique, vous pouvez configurer le service pour qu'il s'exécute sous un autre utilisateur (cliquez avec le bouton droit sur service -> Propriétés -> Connexion). Je devais le mettre comme USER @ DOMAIN, par exemple. [email protected] ou à peu près. Je ne suis pas sûr de l'aspect d'un paramètre cmd, mais je m'attendrais à ce qu'il en existe un.
De plus, je ne sais pas trop en quoi cette solution de contournement fait une différence, car sur mon Jenkins, SYSTEM et USER sont configurés pour disposer des mêmes droits sur le système et sont bien sûr tous deux reconnus comme "Jenkins" par télécommande. Pourtant, ça fait l'affaire pour moi. Des idées plus profondes sont les bienvenues.
J'ai essayé la plupart de ce qui précède:
Spécifiez l'emplacement de git . Définissez l'utilisateur du service . Exécutez-le en tant qu'administrateur.
Rien de tout cela n'a fonctionné. Finalement décidé de désinstaller git64 et d'installer git32 ... changea le chemin d'accès git au nouvel emplacement (dans x86 Program Files). Et tout a fonctionné.
J'ai rencontré ce problème récemment.
Nous avons ajouté des éléments dans notre PATH EV lorsque nous avons essayé de connecter Winium et Selenium à notre instance Jenkins.
Nous avons retiré ces éléments, mais Jenkins semblait toujours s’en tenir aux valeurs. Après un peu de dépannage: redémarrer Jenkins; redémarrer le serveur Jenkins; régler les véhicules électriques au niveau du nœud; etc., nous avons redémarré le service Jenkins JNLP sur l’esclave Windows .
Et il vécurent heureux pour l'éternité.
Dans mon cas, j'ai commencé à avoir cette erreur exacte après avoir mis à jour Git sur certains de mes machines de construction (via Chocolatey, en utilisant le paquetage "git.install") de 1.9.4 à 2.5.0. L'ancienne installation 1.9.4 était un paquet 32 bits, mais le nouveau est un 64 bits. Par conséquent, l'emplacement d'installation par défaut est passé de C:\Program Files (x86)\Git à C:\Program Files\Git. Le chemin 64 bits était configuré sur le maître Jenkins (car il contenait la version la plus récente de Git), mais la version 32 bits la plus ancienne était toujours installée sur certains esclaves. Ils ont donc tenté d'utiliser un chemin incorrect. J'aurais pu remplacer le chemin Git pour des esclaves individuels, mais la solution la plus simple pour moi consistait simplement à mettre à niveau tous les esclaves vers la version 64 bits la plus récente.
J'étais confronté à un problème similaire et j'ai constaté que je devais ajouter git à ma variable d'environnement PATH pour un esclave Windows. Je pense que la suggestion 2 de @dhj pourrait également fonctionner dans ce cas.
J'ai trouvé cette solution de contournement sur Jenkins Jira.