How can I get SCP and ftp (from command line, not plugin) working within hudson

Question

I am running hudson CI server on a win32 machine. After the build succeeds I want the exe created to be put on a public website. The hudon plugins for SCP and ftp were not working the way I wanted (mostly because it chooses some odd directories for where to place them) so I made my own script for a command line scp that hudson calls.

For some reason though when run under the hudson environment the scp bat file hangs. It works fine when I call it from a command line though on the same machine.

Apparently this also fails when run from the task scheduler.

Can anyone think of a reason this would not work from a hudson or scheduler environment?

pscp.exe -batch -q -pw mypassword ..\..\installers\Output\myfilename  [email protected]:domains/domain.com/html/downloads

(Note that 'domain.com' is a replacement for my domain name...)

Again, when I call that bat file from the command line it works just fine.

Note also - the reason I call a bat file is because I replace the filename with a svn WCREV command - since hudson is brain dead and can't do that replacement in either the scp or ftp plugins or on the command line calls. This method should work fin but it hangs.

pscp is a command line ssh program associated with Putty.

An additional issue I have is that this project access two svn repositories so hudson gets confused and can't provide the svn rev number at will in places where I expect it to be available. (One repo is for third party things and the other is our code base) We use the svn rev from our code base as part of the identifier to name the installer that is created.

I would be happy to use the ftp or scp from within hudson (The plugins) but they do not seem to work for me at all given the locations that hudson decides to put files (using build numbers - I do not want to use hudson's build numbers to identify builds - I prefer the svn revision) - thus I use the command line versions but those don't work either - they hang the hudson build process.

Answer 1

Ran into the same issue myself. The problem is that pscp (like all of PuTTY) requires the hostkey for the server you're connecting to be loaded into the registry (in HKEY_CURRENT_USER). Without the hostkey, pscp will reject the host as invalid (there should be an error message that shows up in the console output unless you've surpressed it somehow. This is a one-time thing, but needs to be done for each user running the command.

This is the basic process I use:

1. Connect to the server and port using PuTTY. Accept the hostkey when prompted.
2. Run regedit.exe
3. Browse to HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
4. Export the relevant hostkey to a .reg file (right-click on SshHostKeys and select export)
5. Login as the user Hudson runs as an import the exported .reg file

If Hudson is running as Local System, you can use PsExec or the technique described on this MSDN blog to run a command as the Local System account.

Once you've done this once, the command should work run under Hudson.

Edit

The two links just ways to run a command prompt as the Local System. You can tell what user id Hudson runs as by opening the Services control panel (services.msc) and finding the Hudson service and checking what it says under the Log On As column.

If it's not Local System, you should be able to login to Windows as the user and import the reg file. If it's run as Local System (the default) you can't login to Windows and need to use either PsExec or the technique described on the MSDN blog to import the registry file into the Local System's HKEY_CURRENT_USER tree.

Answer 2

How about upgrading your putty with Quest PuTTY. It is based on PuTTY and offers the parameter -auto_store_key_in_cache. This should solve your problem.

See also a similar question on SuperUser.

Answer 3

I solved my problem by using an account that was able to runt he scp commands from the command line. Specifically, in the services configuration I set the hudson service to use another user that I had set up and not the system account.

This is not likely the best way to solve the problem, but it worked for me in the short-term.