Erreur de clonage de Jenkins à distance

J’ai besoin d’aide ici, ça fait une semaine que je suis avec ce problème, je n’arrive pas à comprendre ce qui se passe. Je ne suis pas capable de cloner un repo git à partir d’un nœud esclave (Jenkins). J’ai ajouté la clé ssh, l’hôte et l’esclave (j’ai déjà essayé de générer une seule clé et une pour chaque virtuel et hôte)).

Sur Jenkins:

  • URL: git@github.com:
  • Informations d’identification: Ici, j’ai essayé avec le nom d’utilisateur / mot de passe, le nom d’utilisateur avec le fichier ssh, le nom d’utilisateur avec la clé ssh directement, et -none-.

Il ne semble pas qu’il y ait un problème d’authentification car je peux cloner le repository manuellement à partir de la console (à la fois, esclave et hôte). Je peux aussi me connecter avec

ssh -T [email protected]

donc la clé ssh va bien, mais quand je construis, cela apparaît sur la console:

Construire à distance sur IE10Win7 dans l’espace de travail C: \ Users \ IEUser \ Desktop \

Effacement de l’espace de travail en premier.

Clonage du repository Git distant

Référentiel de clonage [email protected]: .git

git init C: \ Users \ IEUser \ Desktop \ # timeout = 10

ERREUR: Erreur lors du clonage du repository à distance ‘origine’

ERREUR: Erreur lors du clonage du repository à distance ‘origine’

Effectuer une tâche de construction Post …

est-ce que quelqu’un a une idée? J’espère que quelqu’un peut me donner un indice, merci!

J’ai résolu ce problème en définissant le chemin d’outil du nœud esclave, en sélectionnant git et en définissant sa valeur sur

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. Faire reculer le plugin git n’a pas aidé, mais j’ai fait quelques autres choses pour le faire fonctionner. J’ai énuméré tous les trois ici, mais c’est probablement (2) que le problème a été résolu. Apparemment, l’exécutable git a été réinitialisé à la valeur par défaut. Donc, 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 être utiles.

(1) Le git par défaut sur une installation Linux de jenkins pointe geenrally vers / usr / lib … Vous devez spécifier un fichier GitForWindows distinct qui pointe vers la version de 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 \ Local logins just use  OK to save and exit Right-click again and select "Restart" to make the changes active. 

J’ai trouvé une solution de rechange décente dans mon cas. La commande git clone hérite toujours de son propriétaire de processus, ce qui peut faire 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 client Git).

Donc, pour 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 le git clone appelé depuis Jenkins peut être rejeté car il appelle la télécommande en tant que SYSTEM. Dans Services, où vous démarrez généralement Jenkins via l’interface graphique, vous pouvez configurer le service pour qu’il fonctionne en tant qu’utilisateur différent (clic droit sur le service -> Propriétés -> Connexion). Je devais le mettre comme USER @ DOMAIN, par exemple [email protected] ou alors. Je ne suis pas sûr de ce à quoi ressemblerait un paramètre cmd, mais je pense qu’il y en a un.

Aussi, je ne sais pas trop quelle différence cette solution apporte à la fin, car sur Jenkins, SYSTEM et USER sont configurés pour avoir les mêmes droits sur le système et ils sont bien sûr tous deux reconnus comme “Jenkins” par la télécommande. Pourtant, il fait le tour pour moi. Des idées plus profondes sont les bienvenues.

Je faisais face à un problème similaire et j’ai constaté que je devais append git à ma variable d’environnement PATH pour un esclave Windows. Je pense que la suggestion de @dhj 2 pourrait aussi bien fonctionner dans ce cas.

J’ai trouvé cette solution sur Jenkins Jira.

Dans mon cas, j’ai commencé à obtenir cette erreur exacte après avoir mis à jour Git sur certaines de mes machines de build (via Chocolatey, en utilisant le package “git.install”) de 1.9.4 à 2.5.0. L’ancienne installation 1.9.4 était un package 32 bits, mais le nouveau est un package 64 bits. L’emplacement d’installation par défaut est donc passé de C: \ Program Files (x86) \ Git à C: \ Program Files \ Git. Le chemin d’access 64 bits était configuré sur le maître Jenkins (étant donné qu’il contenait la nouvelle version de Git), mais l’ancienne version 32 bits était encore installée sur certains esclaves, de sorte que les esclaves tentaient d’utiliser un chemin incorrect. J’aurais pu écraser le chemin Git pour les esclaves individuels, mais la solution la plus simple pour moi était simplement de mettre à niveau tous les esclaves vers la nouvelle version 64 bits.

J’ai essayé la plupart des éléments ci-dessus:

Spécifiez l’emplacement de git. Définir l’utilisateur du service. Exécuter en tant qu’administrateur.

Rien n’a fonctionné. Finalement décidé de désinstaller git64 et d’installer git32 … changé le chemin d’access git au nouvel emplacement (dans les fichiers de programme x86). Et tout a fonctionné.

J’ai rencontré ce problème récemment.

Nous avions quelques éléments dans notre EV PATH que nous avions ajouté en essayant de connecter Winium et Selenium à notre instance Jenkins.

Nous avons enlevé ces objects, 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 VE au niveau du nœud; etc., nous avons redémarré le service JNLP Jenkins sur l’esclave Windows .

Et il vécurent heureux pour l’éternité.