Whilst trying to get my new build server to work I came across this error:

ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: File not found: revision 22, path '/BuildServers/Trunk/Office/Server' . Process command: C:\Program Files\Subversion\bin\svn.exe log svn://localhost/BuildServers/Trunk/Office/Server -r "{2009-07-07T10:53:29Z}:{2009-07-07T10:54:13Z}" --verbose --xml --username build.server --password build --non-interactive --no-auth-cache at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetModifications(IIntegrationResult from, IIntegrationResult to) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)

After double checking all my settings and paths I realised that the truckUrl property is case sensitive:

<trunkUrl>svn://localhost/BuildServers/trunk/Office/Server</trunkUrl>
Doh!

Posted in: Continuous Integration  Tags:

After installing CruiseControl.Net 1.4.4 I used one of my projects that was working fine in v1.4.2 but when I tried to kick off the build I received the following error:

ThoughtWorks.CruiseControl.Core.CruiseControlException: Unexpected exception caught on server ---> ThoughtWorks.CruiseControl.Core.CruiseControlException: Unable to find Log Publisher for project so can't find log file at ThoughtWorks.CruiseControl.Core.Project.GetLogPublisher() at ThoughtWorks.CruiseControl.Core.Project.GetLogDirectory()

After a brief bit of investigation the only way I could get this working was to add <xmllogger /> as follows:

<publishers>
<statistics />
<xmllogger />
</publishers>

Reading the documentation it says that if you do not specify the xmllogger then cc.net will add this by default.  Using the Configuration Validation Tool it also shows on the processed tab that this indeed is not the case.

Posted in: Continuous Integration  Tags:

Today I'm installing cc.net v1.4.4, previously I've been using v1.4.2 and I noticed since v1.4.3 the introduction of the CruiseControl.Net Configuration Validation Tool. 

This handy tool does what it says on the tin, just point it at your config file and it'll tell you if your file is valid or not!  Also another useful feature is to look at the processed results, I find this useful to see what defaults cc.net is using and any other tags that I might not have known about.

image


Posted in: Continuous Integration  Tags:

By default Cruise Control stores the all important ccnet.config file in %ProgramFiles%\CruiseControl.NET\Server,  if you didn’t know CC.Net also monitors this file and will rebuild itself if it detects a change. 

Now the main problem with the default location for ccnet.config is that this is not under source control, so if your build server happens to suddenly “disappear” (this has happened to me) then you’ve lost all of your project configuration.

What I like to do is store ccnet.config in source control and create a project in ccnet.config that monitors this file. 

Benefits:

  • CCNet.Config is safe and sound versioned under source control
  • Any developer can check out the file and create new projects
  • Best of all Cruise Control will detect any changes and magically rebuild itself!  How cool is that!?

Here’s how I do it:

  1. Create a new folder structure under source control Build Servers\[SERVER_NAME]\Server
    (By using the build server name you can store multiple server ccnet configs)
  2. Checkin your %ProgramFiles%\CruiseControl.NET\Server\ccnet.config file to the Server folder in step 1
    (Copy it to your working folder first!)
  3. Modify the following line in %ProgramFiles%\CruiseControl.NET\Server\ccservice.config replacing the path with the location of your working copy on location on the build server.
  4. <add key="ccnet.config" value="C:\Builds\CCNet\Server\ccnet.config"/>
  5. Create a new project in ccnet.config like the following:
  6. <!-- 
      *********************************************************************************************************************************************
      Cruise Control Config file - Monitors for changes to the main cruise control project config file 
      *********************************************************************************************************************************************
      -->
    <project>
      <name>Lon-Build-01 - Config File</name>
      <webURL>http://Lon-Build-01/ccnet/server/local/project/Lon-Build-01+-+Config+File/ViewProjectReport.aspx</webURL>
      <triggers>
        <intervalTrigger seconds="60"/>
      </triggers>
      <workingDirectory>c:\builds\CCNet\Server</workingDirectory>
      <modificationDelaySeconds>0</modificationDelaySeconds>
      <sourcecontrol type="svn">
        <executable>C:\Program Files\SlikSvn\bin\svn.exe</executable>
        <trunkUrl>svn://Lon-Build-01/BuildServers/Trunk/Lon-Build-01/Server</trunkUrl>
        <tagOnSuccess>false</tagOnSuccess>
      </sourcecontrol>
     
      <publishers>
        <statistics />
      </publishers>
     
      <externalLinks>
        <externalLink name="IIS Root Web on Localhost" url="http://localhost/" />
      </externalLinks>
    </project>
  7. Restart the Cruise Control service

Now you have a versioned ccnet.config file and an auto rebuilding build server!

 

PS Don’t forget to add the new proecjt in CC tray!


A key thing to do in any continuous integration environment is to make sure you have a clean directory for each build run.  There’s a few ways of doing this but this is the way I prefer to do a prebuild clean before letting CC.Net retrieve the source code.

<;!--  
    Pre build tasks 
    User powershell to CLEAN the directory, it doesn't remove the parent as this will be in use by cc.net 
-->; 
<prebuild> 
  <;exec> 
    <;executable>powershell.exe</executable> 
    <;buildArgs><![CDATA[-command "& {if( [System.IO.Directory]::Exists($pwd) ){dir $pwd | ri -recurse -force}}"]]></buildArgs> 
  <;/exec> 
</prebuild>

This uses powershell to perform a quick delete on the working folder.


Dan posted on June 2, 2009 23:51

CC.Net will quite happily work with TFS but you'll need to install a plugin and the Microsoft Visual Studio Team Explorer client which will install the assemblies necessary to make the TFS CC.Net plugin work.

So lets download the software to make this work:

  1. Extract the contents of the CC.Net Plugin to a temp directory
  2. Copy the ccnet.vsts.plugin.dll assembly into the server directory for CCNET (%programfiles%\CruiseControl.NET\server).
  3. Install Visual Studio Team System 2008 Team Explorer


Configure ccnet.config project

Here's an example of the configuration I'm using:

    <sourcecontrol type="filtered">
<sourceControlProvider type="vsts" autoGetSource="true" applyLabel="true">
<server>http://server:8080</server>
<username>build.server</username>
<password>buildy</password>
<domain>QWERTY</domain>
<project>$/App/Lib</project>
<workingDirectory>C:\Builds\App</workingDirectory>
<workspace>[SERVER_NAME]</workspace>
<deleteWorkspace>false</deleteWorkspace>
</sourceControlProvider>
<exclusionFilters>
<userFilter>
<names>
<name>admin</name>
</names>
</userFilter>
</exclusionFilters>
</sourcecontrol>

Troubleshooting

You receive the following in CC.NET:

Microsoft.TeamFoundation.VersionControl.Client.WorkspaceExistsException: The workspace CCNET ...

Make sure you add the workspace setttings, I use the server name to avoid any potential conflicts in the workspace. For example where I'm working now they use the same domain user for all build servers, incidentally My Documents are mapped to a shared network drive as well. In this case if we all used CCNET there'd be a problem, as I found out (the hard way)!

        <workspace>[SERVER_NAME]</workspace>
<deleteWorkspace>false</deleteWorkspace>

 

Perform a TF action from the command line

  1. Ensure that the global path variable contains c:\program files\Microsoft Visual Studio 9.0\Common7\IDE
  2. Shell out to the command line and type in TF workspaces, you should get a list of available TFS workspaces, if CCNET has been running your'll see items with a comment of "Temporary CruideControl.NET"

Calendar

«  March 2010  »
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234
View posts in large calendar

Authors

Recent Comments

Banners

Theme Grabber
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010 Dan Gibbons .Net Developer