This is most definitely filed under note to self. This may be of no interest to anyone else, but I'm jotting these notes down before I forget the details (and pain). If anyone else gets any benefit from them - you're welcome.

After trying a lot of different things on two different machines I've finally got the continuous integration service Jenkins connecting to our unfuddle account and cloning a repository. Sounds really simple, doesn't it!

The best notes I found were these, although I ended up installing on a windows xp machine instead but that mattered little. There are some useful clues here as well. Both of these pointed out that Jenkins was running under the local system account and that therefore I had to make sure private and public keys were visible to that account and not just the domain account.

After an initial attempt at getting it set up on my development machine, I decided to comandeer one of my servers and try again from scratch, following these instructions.

The only deviations were:

  • I used the SSH-Keygen exe installed with Git for Windows to generate the public and private SSH keys (id_rsa and id_rsa.pub) (rather than PuttyGen)
  • I created a new user account at unfuddle for my jenkins service to use
  • I added the SSH public key to my jenkins user at unfuddle to tie the two things together
  • There is no point trying the "C:\Git\bin\ssh.exe" -T git@your.git.server part in the instructions for unfuddle as you will get a Need SSH_ORIGINAL_COMMAND response. This is because unfuddle disallows SSHing to anything other than git repositories. This is an expected response when following those instructions. Skip it and move on.
  • I used a command prompt via PSTools\PSExec and did an explicit clone as git clone git@<subdomain>.unfuddle.com:<subdomain>/<repository>.git to ensure that everything worked. Which it did. Then I moved back to Jenkins.

Finally, within Jenkins set up the url for git as being git@<subdomain>.unfuddle.com:<subdomain>/<repository>.git ignoring the fact that the help says that :

This can be a URL or a local file path. Note that for super-projects (repositories with submodules), only a local file path or a complete URL is valid. For instance, user@host:/path is not a valid URL.

Then running a build (basically doing nothing more than getting the files from git at this stage) resulted in my C:\Program Files\Jenkins\jobs\<jenkins job name>\workspace having a complete set of files. Hurrah! 

Now to make it build...