J'ai réussi à cloner le référentiel Git dans Jenkins sur Git/SSH sous Windows 2008 32 bits. Lorsque j'ai essayé de faire la même chose sous Windows 2008 64 bits, la page Console Output est bloquée ici:
Démarré par l'utilisateur anonymous
Checkout:book / C:\Jenkins\workspace\book - hudson.remoting.LocalChannel@1da691a
Using strategy: Default
Last Built Revision: Revision 5d7ce4ae23c91fb201ee005e6db17bcd795ca965 (Origin/HEAD, Origin/master)
Checkout:book / C:\Jenkins\workspace\book - hudson.remoting.LocalChannel@1da691a
Cloning the remote Git repository
Cloning repository Origin
Lorsque j'arrête la construction (après quelques minutes de blocage), le message d'erreur suivant s'affiche:
ERROR: Error cloning remote repo 'Origin' : Could not clone [email protected]:zeljkofilipin/watirbook.git
ERROR: Cause: Error performing command: C:\Git\bin\git.exe clone --progress -o Origin [email protected]:zeljkofilipin/watirbook.git C:\Jenkins\workspace\book
null
Trying next repository
ERROR: Could not clone repository
FATAL: Could not clone
hudson.plugins.git.GitException: Could not clone
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.Java:1042)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.Java:968)
at hudson.FilePath.act(FilePath.Java:785)
at hudson.FilePath.act(FilePath.Java:767)
at hudson.plugins.git.GitSCM.checkout(GitSCM.Java:968)
at hudson.model.AbstractProject.checkout(AbstractProject.Java:1193)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.Java:567)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.Java:455)
at hudson.model.Run.run(Run.Java:1404)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.Java:46)
at hudson.model.ResourceController.execute(ResourceController.Java:88)
at hudson.model.Executor.run(Executor.Java:230)
git://github.com/zeljkofilipin/watirbook.git
de Jenkins sur les deux machines.[email protected]:zeljkofilipin/watirbook.git
à partir de la ligne de commande sur les deux machinesLa seule différence que je peux remarquer entre les deux machines (sans compter que l'une est une machine virtuelle sur mon ordinateur portable et une autre est une vraie machine en Suisse) est que la première est en 32 bits et la seconde en 64 bits.
Je ne sais pas si cela pourrait être lié, mais l'emplacement de la machine 32 bits est défini sur la Croatie et celui de la machine 64 bits en Suisse (comme vous pouvez le voir à partir de la sortie Git en français).
Pour plus d'informations, veuillez consulter mon article de blog: Jenkins, Windows et Git
J'ai traversé ces douleurs récemment. Le manque de journaux d'erreurs dans ce scénario est particulièrement frustrant: probablement parce que MSysgit invite l'utilisateur sur la console lors d'une tentative de récupération - ce qui ne passe pas par la console Jenkins.
D'après mon expérience, voici quelques éléments clés à surveiller:
<MSYSGIT_ROOT>\cmd\git.cmd
que <MSYSGIT_ROOT>\bin\git.exe
HOME
variable pour Windows esclaves explicitementgit clone
dans une étape de construction "Exécuter Shell/batch". Cela devrait révéler un peu plus d'informations. BTW, vous pouvez faire une env
dans la même étape et peut-être ls %HOME%/.ssh
Je pense que ce qui précède est ce qui m’a donné l’utilisation d’un esclave Jenkins Windows 7 64 bits avec le support de git - bien que j’ai pensé que cela avait plus à voir avec quelques autres détails de configuration que avec 64 vs 32 bits. Bonne chance quand même!
Dans la dernière version de git, il fallait utiliser% GIT_HOME%/cmd/git.exe plutôt que% GIT_HOME%/bin/git.exe pour déterminer le répertoire de base de l'utilisateur exécutant le service Jenkins.
Un autre problème que j'ai rencontré était, ssh.exe ne cherchait pas le dossier %userprofile%/.ssh
pour les fichiers de clé. Au lieu de cela, il regardait le dossier C:\Program Files (x86)\Git\.ssh
qui était vide et qui provoquait un blocage en raison de l'invite d'authentification ssh sur la machine où git repo était situé.
Nous venons de copier les fichiers de clé sous %userprofile%/.ssh
dans C:\Program Files (x86)\Git\.ssh
et le problème est résolu.
Notes tirées d'une dure leçon ... J'ai eu des problèmes pour que ssh fonctionne avec Jenkins en tant que compte d'utilisateur nommé pour ssh + git.
Voici ce que je devais faire pour résoudre le problème:
J'ai essayé avec puttygen et GET_SSH = plink que tous échouaient très mal mais sans erreurs claires.
Comme Windows Jenkins était un esclave, je devais configurer ce nœud pour trouver le git dans cmd au lieu de bin comme décrit par inger. Pour ce faire, allez dans Gérer Jenkins, Gérer les nœuds, cliquez sur le nœud approprié, cliquez sur Configurer, puis allez dans les emplacements des outils. Recherchez git dans la liste déroulante, puis spécifiez le chemin d'accès à git.exe (y compris git.exe), par exemple C:\Program Files\Git\cmd\git.exe.
J'ai confirmé que le cmd/git.exe fonctionnait différemment du bin/git.exe à la fois en ligne de commande et avec un travail jenkins temporaire à l'aide de la commande git (au lieu d'un repo scm).
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin
Ajoutez simplement une connexion utilisateur activée pour ssh à Jenkins et tout devrait fonctionner normalement.
Lorsque vous devez utiliser les options de configuration d'un fichier de configuration par utilisateur, par exemple. ~/.ssh/config vous pouvez les mettre dans C:\Program Files (x86)\Git\Etc\ssh\ssh_config, les fichiers de clé peuvent être placés dans C:\Program Files (x86)\Git.ssh
Si votre compte est rattaché au domaine. Ensuite, vous devez vous assurer que l'utilisateur pour lequel l'esclave Jenkins est exécuté. Pour cela, ouvrez Paramètres-> Propriétésde "Jenkins Slave" -> Connexion. et choisissez nécessaire utilisateur de domaine pour une exécution correcte.