CruiseControl.NET and TFS 2013

CruiseControl.NET and TFS 2013

So in our move to TFS 2013 from SVN we do not initially plan to change our build process over to TFS yet.  Currently we are on CruiseControl.NET 1.8.3.  Upon research this release doesn't officially support TFS 2013.  That was a later enhancement in 1.8.5.  However we are not prepared to upgrade to 1.8.5 (one change at a time).  What I am left with is trying to get 1.8.3 to work with TFS 2013.  It does have a "vsts" source control provider.  Below are my notes on getting this working.

Source Control Path Filters

If you specify a workspace name CCNET will create it but it doesn't appear to be in a format 2013 UI or command lines understand.  What I mean is if you list the workspaces via command line or in the UI you will not see it.  However it is there.  When I checked a file in no build triggered.  I recommend manually creating the workspace on your server and specifying it in the name.  Even with that I get this error when I forced a build (it never triggered):

ThoughtWorks.CruiseControl.Core.CruiseControlException: Warning default.htm - Unable to perform the get operation because the file already exists locally Warning help.htm - Unable to perform the get operation because the file already exists locally Warning D:\Dev\SCM\main\WebSites\SCM\default.htm - Unable to perform the get operation because the file already exists locally Warning D:\Dev\SCM\main\WebSites\SCM\help.htm - Unable to perform the get operation because the file already exists locally at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vsts.LookForErrorReturns(ProcessResult pr) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FilteredSourceControl.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)

I had to go into the TFS Explorer UI and override the files.  I wonder if it was because I forgot to set the workspace to a server workspace with Checkin times.  After fixing the workspace and editing the file again I was able to force a build with no issue.  However it still is not picking up on changes and triggering automatically.

I believe it has something to do with my path filters or project in the ccnet.config or my workspace mappings in TFS.

In SVN my path filter appended to the URL so if you specified your <turnkURL> as http://svnserver/svn/trunk you could use a path filter of /branchUnderTrunk/**/*.  This would trigger a build for any file under http://svnserver/svn/trunk/branchUnderTrunk.  This doesn't work for TFS.  Below are some examples of what did work for me.  They include wild cards before the path and using the full TFS path.

<inclusionFilters>
   <pathFilter>
      <pattern>/Processes/**/*.*</pattern> <!-- Does not work -->
   </pathFilter>
   <pathFilter>
      <pattern>**/Scripts/General/**/*.*</pattern> <!-- Does work -->
   </pathFilter>
   <pathFilter>
      <pattern>$/TFSProject/TRUNK/WebSites/**/*.*</pattern> <!-- Does work -->
   </pathFilter>

</inclusionFilters>

Source Control Project and Working Directory

This is what I have learned about the <project> and <workingDirectory> elements in the ccnet config for the vsts source control block.  The <project> element doesn't necessarily have to the just the project root ($/TeamProject).  It can be a subdirectory.  This matches up to the Source Control Folder mapping in the TFS workspace UI.  The <workingDirectory> then maps to the Local Folder.

As I changed these settings and did an edit on the workspace I would see the changes.  Keep this in mind as what ever you initially set in the workspace you manually created may not be what it is after Cruisecontrol.NET alters it.

If your workspace in SVN only had certain subfolders locally and not the whole folder structure you can mimic that by cloaking the folders you don't want to sync by editing the TFS workspace.  After doing this and kicking off another build CCNET did not alter the workspace config.