Another CCNet patch
Here is another patch for CruiseControl.Net. This patch provides support for a Robocopy SourceControl provider. This gives a significant performance increase over the FileSystem SourceControl provider. To integrate this I needed to adjust how CCNet determined if an executable had succeeded, it used to rely on the exit code of the executable being 0 to indicate success, but Robocopy is more complex than that.
And here are the source files and test harness for the robocopy source control provider. I’ve found this to give much better performance than the file system provider and it supports the removal of deleted files and file and directory exlusions.
The required source control block looks something like this:
<robocopy> <executable>C:\Windows\System32\Robocopy.exe</executable> <autoGetSource>true</autoGetSource> <repositoryRoot>E:\CC-Build\Build\5.2.1\VS2005-x86\Deploy\JetByteTools\Admin</repositoryRoot> <workingDirectory>Admin</workingDirectory> <additionalArguments>/XD Output /XF *.idb</additionalArguments> </robocopy>
<executable> is optional and defaults to C:\Windows\System32\Robocopy.exe which is where the exe lives on vista, if you’re using the XP then you need to supply the path to where the resource kit was installed…
<additionalArguments> allows you to pass in any additional robocopy arguments that you want to supply. This is handy for
/XF to exclude directories and files from the comparison and the copy.
By default the following arguments are used:
/MIR -MIRror a directory tree (equivalent to
/NP -No Progress - don’t display % copied.
/X -Report all eXtra files, not just those selected.
/TS -Include source file Time Stamps in the output.
/FP -Include Full Pathname of files in the output.
/NDL -No Directory List - don’t log directory names.
/NS -No Size - don’t log file sizes.
/NJH -No Job Header.
/NJS -No Job Summary.
with the addition of “
/L” being specified for the get modifications call; I don’t think you can break the output format by providing additional arguments that I’m not expecting, but let me know if the history parser barfs with certain arguments…
If someone can improve the history parser then that would be good, I get the feeling that it should be possible to use a single regex; which may or may not be an improvement…