Pre-build task - deleting the working copy in CruiseControl.NET

Question

I'm currently in the process of setting up a continuous integration environment at work. We are using VisualSVN Server and CrusieControl.NET. Occasionally a build will fail and a symptom is that there are conflicts in the CruiseControl.NET working copy. I believe this is due to the way I've setup the Visual Studio solutions. Hopefully the more projects we run in this environment the better our understanding of how to set them up will be so I'm not questioning why the conflicts happen at this stage. To fix the builds I delete the working copy and force a new build - this works every time (currently). So my questions are: is deleting the working copy a valid part of a continuous integration build process, and how do I go about it?

I've tried solutions including MSTask and calling delete from the command line but I'm not having any luck.

Sorry for being so wordy - good job this is a beta :)

Envisage

CleanCopy for Subversion is implemented now, in version 1.4.1. You just have to set CleanCopy to true in your config – Emu

Answer 1

Doing a full delete before or after your build is good practice. This means that there is no chance of your build environment picking up an out of date file. Your building exactly against what is in the repository.

Deleting the working copy is possible as I have done it with Nant.

In Nant I would have a clean script in its own folder outwith the one I want to delete and would then invoke it from CC.net.

I assume this should also be possible with a batch file. Take a look at the rmdir command http://www.computerhope.com/rmdirhlp.htm

@pauldoo

I prefer my CI server to do a full delete as I don't want any surprise when I go to do a release build, which should always be done from a clean state. But it should be able to handle both, no reason why not

Subak

Answer 2

@jamie: There is one reason why you may not be able to do a clean build every time when using a continuous integration server -- build time. On some projects I've worked on, clean builds take 80+ minutes (an embedded project consisting of thousands of C++ files to checkout and then compile against multiple targets). In this case, you have to weigh the benefit of fast feedback against the likelihood that a clean build will catch something that an incremental build won't. In our case, we worked on improving and parallelizing the build process while at the same time allowing incremental builds on our CI machine. We did have a few problems because we weren't doing clean builds, but by doing a clean build nightly or weekly you could remove the risk without losing the fast feedback of your CI machine.

Mccrae

Answer 3

If you check out CC.NET's jira there is a patch checked in to implement CleanCopy for Subversion which does exactly what you want and just set CleanCopy equal to true inside your source control block just like with the TFS one.

Emu

Answer 4

It is very common and generally a good practice for any build process to do a 'clean' before doing any significant build. This prevents any 'artifacts' from previous builds to taint the output.

A clean is essentially what you are doing by deleting the working copy.

Declaration

Answer 5

@Brad Barker

Clean means to just wipe out build products.

Deleting the working copy deletes everything else too (source and project files etc).

In general it's nice if you're build machine can operate without doing a full delete, as this replicates what a normal developer does. Any conflicts it finds during update are an early warning to what your developers can expect.

---

@jamie

For formal releases yes it's better to do a completely clean checkout. So I guess it depends on the purpose of the build.

Shoshonean