SVN "Night" tag builds with CruiseControl.Net

Question

How can I make an overnight or other scheduled build for CruiseControl.NET without duplicating a project?

In my current configuration, every 60 seconds I check the trunk using Subversion, starting up MSBuild, then either NUnit or MSTest.

I would like to return SVN as a tag, but I don't want it on every successful build. I want him to make an overnight assembly or some other schedule. It seems a little tedious for me to have two CruiseControl.Net projects with the same options. What is the best way to handle this?

As a bonus, I would like it to be created as a release build and pass the binaries in the same tag.

Answer 1

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

The first project is built as usual when the developer checks any code.

The second project starts only after a certain time (for example, 11 pm) and will only work if the first project shows a successful build.

Therefore, I use the second project to run user interface tests at Selenium in the middle of the night, not executing them during the day and taking up the build machine when developers need it.

Here is what I did for this: in my ccnet.config file, my second project has this as 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 version control section has the following:

 <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> 

... ...

Accordingly, it is set to false, so the project does not delete the code, but uses what is already there.

Then in my task a little further down, I pass the flag through NAnt to tell him to run UI tests for my projects, since the first project in the ccnet.config file already completed the build process but then ignores the user interface tests.

Does it help at all? I can expand it if this is the direction you want to enter.

Answer 2

I have no solution for your problem with duplicate ccnet projects. but I will tell you how we use ccnet (and we are very happy with this).

we have 20 projects on the build server and several branches for the release of previous versions. we are just starting to build on demand using the cctray application. therefore, after the developer has completed the implementation of the function, he clicks the "Force build" button, and ccnet starts to do its job (assembly, testing, tag, copying the assembly to a network drive, notifying other developers, ...).

the advantage is that developers can decide when to start building. projects that have not changed are not built. projects with work in progress can be built a few months later, only when the developer believes that he needs an assembly.

One idea that comes to mind for novice night collectors would be to use the ccnet remote access interface (which also uses cctray), connect it to the ccnet instance, and call the force-build-method at midnight.

regarding "compiling binaries for the same tag":

there is a problem in ccnet that makes it sometimes tag the revision from the outside and sometimes mark the working copy. it does this depending on whether there have been changes since the last build (in this case it tags the revision from the trunk) or if there have been no changes since the last build (in this case it doesn't tag the working copy).

This is quite annoying because you never know what will be done - in the first case, your binaries will not be committed, in the second case they will.

we actually fixed ccnet so that it always commits the working copy so that we get deterministic behavior. I once filed a patch, but he never made it in ...