4

We had Hudson set up with Git + OpenSSH on Windows Server 2003 Enterprise and it was working fine for a while. Then suddenly, it started to hang during a clone at 12% always, we suspected maybe the files had gotten too big. (It is still working fine on all other machines, Windows Server 2003 standard, Windows 7 Enterprise), just this one server.

So we switched to Putty instead of OpenSSH, and it worked from gitBash and gitExtensions, but fails still from Hudson. Since I've read that there are some concerns regarding the ssh key loading properly for plink, I have set GIT_SSH to a script that will load putty with the key and that works fine from gitBASH, but it still fails with Hudson.

Here is the output of the failure using PUTTY:

    Started by user anonymous
Checkout:workspace / <http://WINDOWS2003SERVER:8080/job/PROJECT/ws/> - hudson.remoting.LocalChannel@1c57a92
Using strategy: Default
Last Built Revision: Revision 2a56d9738e7c0af810e70e2e2051c41bd44f4252 (origin/master) Checkout:workspace / <http://WINDOWS2003SERVER:8080/job/PROJECT/ws/> - hudson.remoting.LocalChannel@1c57a92
GitAPI created
Cloning the remote Git repository
Cloning repository origin
$ C:\bin\Git\bin\git clone -o origin git@GITSERVER:project.git <http://WINDOWS2003SERVER:8080/job/PROJECT/ws/>
ERROR: Error cloning remote repo 'origin' : Could not clone git@GITSERVER:project.git
ERROR: Cause: Error performing C:\bin\Git\bin\git clone -o origin git@GITSERVER:project.git <http://WINDOWS2003SERVER:8080/job/PROJECT/ws/>
Command returned status code 128: Cloning into <http://WINDOWS2003SERVER:8080/job/PROJECT/ws/...>
fatal: The remote end hung up unexpectedly

    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:809)
     at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:740)
     at hudson.FilePath.act(FilePath.java:756)
     at hudson.FilePath.act(FilePath.java:738)
     at hudson.plugins.git.GitSCM.checkout(GitSCM.java:740)
     at hudson.model.AbstractProject.checkout(AbstractProject.java:1171)
     at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:480)
     at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:412)
     at hudson.model.Run.run(Run.java:1362)
     at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
     at hudson.model.ResourceController.execute(ResourceController.java:88)
     at hudson.model.Executor.run(Executor.java:145)

We are not strict with our SSH protocol so long as it works, If someone can possibly tell me why with openSSH it fails, or why Hudson fails with putty and any solutions, I would be very grateful!!

Nerdia
  • 101
  • 1
  • 9
  • We have a git server running on fedora, and have perfectly good jobs occasionally give this 128 error. They mostly run, and the keys are all good, but we cannot explain why sometimes the git interactions blow up like this. – Danny Staple Jan 21 '11 at 15:05

4 Answers4

1

I couldn't ever figure out why openSSH wasn't working, but I did finally get everything working with PuTTY.

My solution was as follows: I created a batch file called: myplink.bat, that would execute putty with the private key and not require pageant to be running. Inside that file was the following:

@echo off
c:\pathto\plink.exe -i c:\pathto\id_rsa.pub

Opening up a gitbash prompt and changing GIT_SSH to this path would only work for that instance, in order to get it to be permanently set for gitbash I modified c:\pathto\git\etc\profile and added at the end:

export GIT_SSH=c:\pathto\myplink.bat

I also modified c:\pathto\git\cmd\git.cmd And added:

@set GIT_SSH=c:\pathto\myplink.bat

This fixed git bash, but hudson would still fail, leaving me to believe hudson's environment gets changed for git somehow. Then in hudson, i went to manage hudson -> configure settings -> environment variables I made sure it was checked, and added: name: GIT_SSH value: c:\pathto\myplink.bat

I restarted the hudson service, and it finally worked.

Please note if you have spaces in any of your paths, that might screw up stuff too, so try to keep your paths space free.

Hope this helps others who have issues with hudson+git+putty.

Nerdia
  • 101
  • 1
  • 9
  • Thank-you! Thank-you!!! I have been whacking my head over this since yesterday evening. I found all kinds of work-arounds and suggestions but this is what finally worked for me. When I am done, I will followup with a post detailing the end-to-end solution of getting jenkins up on windows with git and putty - so far as I can tell nobody has posted a complete solution. – Andrew May 24 '11 at 15:00
0

You don't have the public key on your git server. Do this from the hudson server when logged in as 'git'.

ssh -v gitserver

Study the output. You should NOT get prompted for a password.

If you do, or have other problems, you don't have your ssh keys set up.

hope this helps

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
0

You have to check the following:

  1. You are using ssh keys of the user who ran hudson daemon. For example, if user=hudson, then you should log on as hudson and generate ssh keys
  2. You have loaded your public key to your server (github, assembla) from correct .ssh/id_rsa.pub file i.e. for the same user who ran hudson daemon
  3. You have added RSA fingerprint of your server to your .ssh/known_hosts file
a_fan
  • 383
  • 2
  • 22
0

I have the same problem running on linux(Ubuntu) Server. This link(http://adhockery.blogspot.com/2009/11/git-and-hudson.html) fixed my problem.

Below text is copied from the link.

It turns out Git needs a username to be set and the hudson user that the Debian package creates when Hudson is installed doesn't have one. Easily fixed by using sudo nano /etc/passwd to add Hudson,,, into the hudson user's entry (if you look at your own entry you should see where it needs to go).

firemonkey
  • 329
  • 4
  • 18