Tag SVN “Nightly” Builds with CruiseControl.Net

rajeshkumar created the topic: Tag SVN “Nightly” Builds with CruiseControl.Net
How would I do a nightly or other scheduled build for CruiseControl.NET without having a duplicate project?

In my current config, every 60 seconds, I am checking out the trunk using Subversion, running MSBuild, then either NUnit or MSTest.

I would like to commit back to SVN as a tag, but I don’t want it on every successful build. I want it to make a nightly build or some other set schedule. To me, it seems a bit tedious to have two CruiseControl.Net projects with basically the same options. What is the best way to handle that?

As a bonus, I would like it to build as a release build and commit the binaries in the same tag.
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Re:Tag SVN “Nightly” Builds with CruiseControl.Net
i’ll tell you how we use ccnet (and we’re quite happy with it that way).

we’ve got 20 projects on the build server and several release branches of previous versions. we only start builds on demand using the cctray application. so after a developer is done implementing a feature, he clicks the “force build” button and ccnet starts to do its thing (build, test, tag, copy build output to a network drive, notify other devs,…).

the advantage is that devs can decide when to start a build. projects that haven’t changed aren’t built. projects with work in progress can be built several commits later, only when a developer thinks that he needs a build.

one idea that comes to mind for starting nightly builds would be to use ccnet’s remoting interface (which is also used by cctray), connect it to the ccnet instance and call the force-build-method at midnight.

concerning “committing binaries to the same tag”:

there is a problem in ccnet that causes it to sometimes tag a revision from the trunk and sometimes to tag the working copy. it does this depending on if there were changes since the last build (in which case it tags the revision from the trunk), or if there were no changes since the last build (in which case it tags the working copy).

this is pretty annoying because you never know what will be committed – in the first case your binaries won’t get committed, in the second case they will.

we have actually patched ccnet ourselves to make it always commit the working copy so we get deterministic behaviour. i have once submitted the patch but it never made it in…
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn