Running Cruise Control .NET as a Service

Answer 1

Hmmm - I may have answered my own question here (or not, only time will tell).

For some reason CCNet does not appear to be using the credential in the config file (don't know why). When it calls SVN it waits for a password to be entered, even if the user cannot see it, and then times out when it doesn't get one.

By accessing SVN from the command line the password prompt is visible and can be entered, moreover the password is cached in %app_data%\Subversion\auth\svn.simple inside an encrypted file for that user. This is why subsequent commands do not prompt for a password and why the console application will run without any problems.

I'm going to configure the CCService now so hopefully this will work as well as the console application does now.

If you have had any similar experiences please let me know. In the meantime I may raise the issue with ThoughtWorks.

Answer 2

As far as i remember, when you run cc.net as a service, it uses another config file then when you run it as a console app. (ccservice.exe.config instead of cc.exe.config).

Answer 3

Dave, It is pretty easy to diagnose if CruiseControl is using the password in the config file or not as you will see the command line in the log and the actual password parameter and password if it is being used, and passed to svn. If you have the password and user in the configuration file and they are not being passed, the first thing I would check is that your configuration file is valid and the config file in the file system is what is actually being used. If you make an invalid change to the configuration file, CC.NET just ignores it as long as the service is running and just keeps using the version it has cached internally without any warnings or messages. So again the only way to verify is to look at the config through the web dashboard and make sure it reflects what you expect, or you could bounce the service at which point it will stop and point out your error. In the end though you can work around this as you did though by caching the password with subversion.

Answer 4

Related to Frederik's response - On our server, we specify the subversion credentials in the project itself. The sourcecontrol block for one of these projects would look something like this:

<sourcecontrol type="svn">
    <trunkUrl>http://myserver/svn/myproject/trunk&lt;/trunkUrl&gt;
    <workingDirectory>C:\source\MyProject</workingDirectory>
    <username>foo</username>
    <password>bar</password>
    <autoGetSource>true</autoGetSource>
</sourcecontrol>