Tag SVN "Nightly" Builds with CruiseControl.Net

How would I do a nightly or other scheduled build for CruiseControl.NET without having 开发者_如何学JAVAa 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.

The only way I have found thus far, is to create another project in the ccnet.config file which relies on the output of the first... here's what I mean.

The first project builds as normal whenever a developer checks-in any code.

The second project only runs after a specified time (e.g. 11pm) and will only run IF the first project shows a successful build.

Therefore, I am using the second project to do the UI tests in Selenium during the middle of the night, without having them run during the day and occupying the build machine for when the devs need it.

Here's what I have done to do this: In my ccnet.config file, my second project has this as it's settings:

<triggers>  
        <multiTrigger operator="And"> 
            <triggers> 
                <projectTrigger project="NameOfProject1" /> 
                <scheduleTrigger time="23:00" buildCondition="ForceBuild">
                    <weekDays>
                        <weekDay>Monday</weekDay>
                        <weekDay>Tuesday</weekDay>
                        <weekDay>Wednesday</weekDay>
                        <weekDay>Thursday</weekDay>
                        <weekDay>Friday</weekDay>
                        <weekDay>Saturday</weekDay>
                    </weekDays>
                </scheduleTrigger>
            </triggers> 
        </multiTrigger>
    </triggers>

In addition, my source control section has this:

<sourcecontrol type="multi">
<sourceControls>   
    <svn>
        <trunkUrl>http://<my-svn-url>:81/svn/<my-project-name>/branches/1.13</trunkUrl>
        <workingDirectory>c:\ccnet\<my-system-name>\<my-project-name></workingDirectory>
        <cleanCopy>false</cleanCopy>
    </svn>

... ...

Whereby the is set to false, so that the project doesn't delete the code, but uses what's there already.

Then in my task a little further down, I'm passing a flag through to NAnt to tell it to only run the UI tests for my projects, as the first project in the ccnet.config file has already run the build process through but then ignores the UI tests.

Does this help at all? I can expand further if this is the sort of direction you want to go in.

i don't have a solution for your problem with the duplicate ccnet-projects. but 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...