Following on from our efforts to automate our build process, I have been experimenting with Continuous Integration using CruiseControl.Net. This integrates the various parts of the build process such as source control, build tools, testing tools etc. and can remove a lot of the grunt work from performing builds. The cool thing about it is that it can be set up to poll the source control system for modifications and trigger a build whenever one of the source files changes so you get early notice of when the build is broken.
The tool is fairly well documented using a wiki. As with many wikis though, some parts of the documentation receive more attention than others. This caused me a few problems as we are using an old version of PVCS for source control and the PVCS docs are a bit thin. I got it working after a bit of trial and error and subsequent browsing of other areas of the site for different source control providers gave some tips that appear to be common to all source providers, so a common section would have been useful.
Installation was fairly simple and I proceeded to set up a simple test project:
<sourcecontrol type="pvcs">
<!--client executable-->
<executable>X:\VM\Win32\Bin\pcli.exe</executable>
<!--PVCS Database-->
<project>S:\PVCS Databases</project>
<subproject>/LIBRARY/.Net/NullableDateTimePicker</subproject>
<workingDirectory >C:\development\LIBRARY\.Net\NullableDateTimePicker</workingDirectory>
<!--<recursive >true</recursive>-->
<autoGetSource >True</autoGetSource>
<labelOrPromotionName >shared_DEV</labelOrPromotionName>
</sourcecontrol>
This configuration did not work and I had to investigate a bit more how it works. What seems to happen is that CruiseControl issues a succession of pcli commands and use the output from each to build further batch files for use by the next command. On my system, these batch files were saved to my temp directory:
C:\Documents and Settings\myname\Local Settings\Temp
When the next command attempted to use the file as input, the directory name was not escaped so the embedded spaces caused it to fail. I worked around this by setting my TEMP and TMP environment variables to point to C:\agtemp\temp this allowed me to proceed to the next step.
Now that the pcli commands were succesfully running, I had to change a source file in order to trigger the build. When I did this, I noticed that the pcli command produced by CruiseControl only got changed files when I had assumed that it would get all files in the project. This does make sense as the structure in PVCS does not neccesarily map directly to the .Net project structure. You are supposed to already have all the source code available in your working directory before starting CruiseControl which then just gets subsequent modifications before performing the build. If you need to get all of it then you can do a get for a specific label or promotion group by adding a </labelorpromotionname> element whose value corresponds to your label or promotion group.
Finally, I wasn't getting any executables even though the build was reported as succesful. This was another mistaken assumption on my part as I thought that it would automatically call MSBuild for the project. I added an MSBuild task to the project and configured it to call my solution file which then resulted in a shiny new dll in the release folder.
Subscribe to:
Post Comments (Atom)
1 comment:
Hello...I was trying to Configure a Cruise Control on PVCS for one of our java based project to automate build process can you please share if you have any documents for configuring PVCS for Cruise Control. Thanks!
Post a Comment