web-dev-qa-db-fra.com

Jenkins suspendu à "Récupération des modifications en amont de Origin"

J'essaie de configurer Jenkins sur un ordinateur Windows Server 2012 et j'éprouve de nombreuses difficultés.

Choses que j'ai faites:

  • Création d'un id_rsa et d'un id_rsa.pub sans mot de passe
  • Création d'un fichier known_hosts pour bitbucket.org en utilisant ssh.exe -T bitbucket.org et acceptant d'ajouter l'hôte.
  • Ajout de E: à la variable HOME globale du système
  • J'ai ajouté ces fichiers à C:/Windows/SysWOW64/config/systemprofile/.ssh ainsi que E:/.ssh
  • J'ai lié ma clé publique à Bitbucket en tant que clé de déploiement.
  • J'ai vérifié trois fois toutes mes URL, noms d'utilisateur, etc.
  • J'ai même extrait manuellement le référentiel pour configurer une base initiale dans C:/Program Files (x86)/Jenkins/jobs/MyProject/workspace/

Et pourtant, il est toujours suspendu à

Building in workspace C:\Program Files (x86)\Jenkins\jobs\MyProject\workspace
Checkout:workspace / C:\Program Files (x86)\Jenkins\jobs\MyProject\workspace - hudson.remoting.LocalChannel@13ca972
Using strategy: Default
Fetching changes from 1 remote Git repository
Fetching upstream changes from Origin

Je lui ai donné environ 20 minutes, donc ce n’est pas une question de vitesse/taille de la pension. Si j'annule, voici ce qui est retourné:

ERROR: Problem fetching from Origin / Origin - could be unavailable. Continuing anyway
hudson.plugins.git.GitException: Error performing command: C:\Program Files     (x86)\Git\bin\git.exe fetch -t Origin +refs/heads/*:refs/remotes/Origin/*
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.Java:780)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.Java:739)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.fetch(CliGitAPIImpl.Java:160)
at hudson.plugins.git.GitAPI.fetch(GitAPI.Java:230)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.Java:793)
at hudson.plugins.git.GitSCM.access$000(GitSCM.Java:57)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.Java:976)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.Java:942)
at hudson.FilePath.act(FilePath.Java:865)
at hudson.FilePath.act(FilePath.Java:838)
at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.Java:942)
at hudson.plugins.git.GitSCM.checkout(GitSCM.Java:1101)
at hudson.model.AbstractProject.checkout(AbstractProject.Java:1364)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.Java:670)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.Java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.Java:575)
at hudson.model.Run.execute(Run.Java:1575)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.Java:46)
at hudson.model.ResourceController.execute(ResourceController.Java:88)
at hudson.model.Executor.run(Executor.Java:237)
Caused by: Java.lang.InterruptedException
at Java.lang.ProcessImpl.waitFor(Native Method)
at hudson.Proc$LocalProc.join(Proc.Java:319)
at hudson.Launcher$ProcStarter.join(Launcher.Java:360)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.Java:769)
... 19 more
ERROR: Could not fetch from any repository
FATAL: Could not fetch from any repository
hudson.plugins.git.GitException: Could not fetch from any repository
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.Java:981)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.Java:942)
at hudson.FilePath.act(FilePath.Java:865)
at hudson.FilePath.act(FilePath.Java:838)
at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.Java:942)
at hudson.plugins.git.GitSCM.checkout(GitSCM.Java:1101)
at hudson.model.AbstractProject.checkout(AbstractProject.Java:1364)
at     hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.Java:670)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.Java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.Java:575)
at hudson.model.Run.execute(Run.Java:1575)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.Java:46)
at hudson.model.ResourceController.execute(ResourceController.Java:88)
at hudson.model.Executor.run(Executor.Java:237)

Je suis au bout du rouleau et j'apprécie toute l'aide que je peux obtenir ..__ Voici quelques articles de choix que j'ai essayés sans amélioration.

Authentifier Jenkins CI pour le référentiel privé Github

Autorisation refusée (publickey) lors de la configuration de Jenkins

Hudson Git Plugin ne fonctionne pas sous Windows

http://computercamp.cdwilson.us/jenkins-git-clone-via-ssh-on-windows-7-x64

gitsshjenkins
31
DTI-Matt

Voici comment j'ai résolu un problème similaire:

Msysgit installe deux git.exe. Un sous C:\Program Files (x86)\Git\bin et un deuxième sous C:\Program Files (x86)\Git\cmd. Le premier ne peut pas être utilisé avec Jenkins. Il va pendre après avoir terminé son travail. Le second fonctionne parfaitement.

Mettez à jour vos paramètres Jenkins Git pour qu'il pointe vers le cmd\git.exe correct et profitez-en!

31
David Gageot

Voici comment je l'ai résolu: 

J'ai exécuté l'outil pysec de sysinternals pour générer un CMD qui s'exécute sous le compte LocalSystem (le même compte que le service jenkins est en cours d'exécution). 

PSEXEC -i -s -d CMD

Dans cette invite de commande, j'ai exécuté la même commande git à partir du répertoire de l'espace de travail que le font les processus GIT.exe suspendus. Par exemple. 

d:\Programmes\Jenkins\jobs\travailname\espace de travail> D:\Programmes\Git\bin\git.exe fetch -t ssh + git: //[email protected]: 9360/data/gitpub/myRepository. git + refs/heads /: refs/télécommandes/origine/

Et voila: on m'a demandé d'entrer "yes" pour ajouter la clé SSH à la liste des hôtes connus. 

8
user2553930

Un autre lien que j'ai trouvé très utile lors de la configuration de Jenkins sous Windows, en particulier lors de l'utilisation du programme d'installation MSI est le suivant: http://opensourcetester.co.uk/2013/06/28/jenkins-windows-ssh/

Et une dernière chose que je n'ai pas trouvée évidente est que vous devez utiliser l'URL SSH lorsque vous vous connectez à Github au lieu de l'adresse https par défaut. J'espère que cela fera gagner du temps à quelqu'un.

2
Woland

Faites simplement l'expérience du gel dans «Récupération des modifications en amont depuis Origin».

L'exécution de Jenkins en tant que service sur une machine Windows semble (d'après ce que j'ai vécu) poser des problèmes lors de l'utilisation de SSL.

Solution de contournement]

  1. Modifiez votre service Jenkins pour l’exécuter sous un compte local.
  2. Assurez-vous que votre compte d'administrateur local est configuré pour effectuer une interaction Git avec SSH.
  3. Redémarrez Jenkins ( détails ).
  4. Si Jenkins ne démarre pas, il est difficile de retirer Git. Supprimez manuellement les processus git et ssh, supprimez votre Java.exe de Jenkins et démarrez manuellement le service Jenkins.

Détails sur pourquoi je choisis cette solution]

J'ai déjà suivi d'autres étapes avant de configurer l'hôte autorisé pour accepter le serveur et pour enregistrer la clé de Jenkins sur le serveur afin de permettre la connexion. Je me suis assuré de pouvoir exécuter avec succès les actions Git sous mon compte Système local (sous lequel le service Jenkins était exécuté). Pourtant, le fetch serait gelé. Pour vérifier que Git et SSL étaient correctement configurés, je suis même allé dans le référentiel Git initialement configuré dans mon répertoire de travaux Jenkins et ai exécuté avec succès une demande d'extraction sous le compte système local . Ça a marché; par conséquent, les clés ont été configurées correctement.

J'ai oublié où j'ai lu cela, mais j'ai entendu dire que des problèmes se posaient lors de l'utilisation de Git/SSH dans un système local. Fort de cette connaissance, j’ai joué avec mon environnement Git et modifié la variable d’environnement GIT_SSH afin d’utiliser plink (avec une combinaison de PuTTY pour mémoriser la clé de serveur, puttygen pour convertir une clé OpenSSL en une clé clés) pour plink. Une fois que je l'ai utilisé avec plink, je n'ai pas trouvé que c'était une solution utilisable. Afin d’utiliser correctement plink, je devais également exécuter pageant sous mon compte système local pour que le service Jenkins négocie correctement les appels SSH. Après avoir réfléchi à la manière de configurer correctement mon état initial au redémarrage, je ne voulais pas mettre tout cet effort à faire en sorte que la connexion SSH fonctionne.

Au lieu de cela, j’ai décidé qu’il était plus simple d’exécuter Jenkins sous mon compte d’administrateur local, qui était également configuré pour gérer le serveur Git. Pas besoin de traiter avec des clés SSH configurées pour le compte système local et mes actions git ont bien fonctionné.

Remarque, la réponse de David Gageot peut s'appliquer à certains. Je n'ai eu à modifier aucun de mes paramètres Git, car lors de l'installation de Git, j'ai choisi l'option Run Git from the Windows Command Prompt qui mappe un chemin d'accès sur le répertoire C:\Program Files (x86)\Git\bin\cmd\.

2
jdknight

J'avais le même problème sur mon ordinateur portable et j'ai pu trouver une solution. Cependant, cela ne s'applique vraiment que si vous exécutez la guerre Jenkins dans un conteneur Web Tomcat configuré comme un service Windows.

Il me suffisait de configurer le service Tomcat pour qu'il se connecte en tant qu'utilisateur Windows au lieu de Système local. 

2
Sheparzo

Pour moi, c’était les permissions sur le dossier $ HOME/.ssh et son contenu. Après l'avoir défini visible pour le groupe d'utilisateurs spécifique, Jenkins a été en mesure d'extraire les modifications après un redémarrage.

1
martoncsukas

J'ai passé quelques heures à essayer de comprendre cela et j'ai découvert que l'ajout du mot de passe à l'URL du dépôt corrigeait le problème:

https://USERNAME:[email protected]/REPO.git

S'il vous plaît noter le: entre nom d'utilisateur et mot de passe

0
IndieTech Solutions

La version 2.6.1 du client Git pour Windows corrige ce problème dans Jenkins. Désormais, “Récupération des modifications en amont depuis Origin” n'a plus de délai.

J'utilise le cmd git dans Jenkins de:

C:\Program Files\Git\cmd\git.exe

0
Thomas T