Haugerns Development Escapades » cruisecontrol.net http://www.haugern.net/blog Morten Haug on development and other curiosities Sun, 31 May 2009 21:56:23 +0000 http://wordpress.org/?v=2.8 en hourly 1 Automatic versioning with CruiseControl.Net and NAnt http://www.haugern.net/blog/automatic-versioning-with-cruisecontrolnet-and-nant/ http://www.haugern.net/blog/automatic-versioning-with-cruisecontrolnet-and-nant/#comments Fri, 11 Jan 2008 18:53:22 +0000 haugern http://www.haugern.net/blog/automatic-versioning-with-cruisecontrolnet-and-nant/ I’ve created a similar setup as David Donald Belcham (a.k.a. igloocoder) mentions in this post for our current project at NOIS.

When I mean similar, we’re using the exact same tools for the job, with NAnt (asminfo task) & CC.NET. But there’s a couple of differences.

New labeller for CC.NET

The first, and minor difference is the labeller. I wanted the versions to work almost as the NAntContrib version task with the automatic build & revision based on day of year and time of day respectively. As most people were running the traditional ymmdd-format for the build, this effectively had to stop at the beginning of 07; 16 bit for the build number breaks that setup. So I settled for an algorithm which won’t break until the year 2066. The major & minor numbers is set manually.

I couldn’t seem to find such a labeller out there, and as I wanted the same number in the CC.NET build-number, and in the assemblies (and in the source control system as well, I’ll get back to that), CC.NET needed to be master. Not finding what I wanted, I created my own labeller for CC.NET, which gives me the build-numbering scheme I wanted.

With the extensibility-points in CC.NET it was great fun, and real easy to deploy my own. Here’s the whole thing:

using System;

using Exortech.NetReflector;

using ThoughtWorks.CruiseControl.Core;

 

namespace Haugern.Util.CCNet

{

    [ReflectorType("versionLabeller")]

    public class VersionLabeller : ILabeller

    {

        [ReflectorProperty("major", Required = true)]

        public int Major;

        [ReflectorProperty("minor", Required = true)]

        public int Minor;

 

        public string Generate(IIntegrationResult integrationResult)

        {

            if(integrationResult == null)

                throw new ArgumentNullException(“integrationResult”);

 

            DateTime now = DateTime.Now;

            return Major + “.” + Minor + “.” + ComputeBuild(now) + “.” + ComputeRelease(now);

        }

 

        private static string ComputeRelease(DateTime now)

        {

            return Math.Round((now.TimeOfDay.TotalSeconds/10)).ToString();

        }

 

        private static string ComputeBuild(DateTime now)

        {

            return now.ToString(“yy”) + now.DayOfYear.ToString(“000″);

        }

 

        public void Run(IIntegrationResult result)

        {

            result.Label = Generate(result);

        }

    }

}

Consistent Build Number

The second difference (well, in his defence, it’s not even mentioned), is that the exact same label should be set back into the source control system. In our case, we’re using TFS Source Control, and with the standard plugin it was easy to apply it there as well.

Now we got this great setup where we can track everything that happens back to the build-number as it is the same across the whole environment:

Application <-> Build server <-> Source Control

Consistent build number across the production line also means every build is a candidate for release.

Should some bug find it way through our thorough unit-testing & qa-scheme into the hands of our customers, finding the right version to search for it will not be a problem!

]]> http://www.haugern.net/blog/automatic-versioning-with-cruisecontrolnet-and-nant/feed/ 2 NUnit swallowed errorcodes http://www.haugern.net/blog/nunit-swallowed-errorcodes/ http://www.haugern.net/blog/nunit-swallowed-errorcodes/#comments Tue, 04 Dec 2007 14:28:31 +0000 haugern http://www.haugern.net/blog/nunit-swallowed-errorcodes/ Update: The header is now in past tense as I figured out a GREAT solution; upgrade from 2.4.1 to 2.4.3!

By accident I earlier today checked in a failing unit-test to our TFS source control. While waiting for the dreaded red light from my CC tray I was about to fix it, when I suddenly discovered…

It didn’t fail the build!

image

 

 

 

 

Going through the build report revealed that it did in fact discover the failing test:

image

 

 

 

 

I couldn’t really live with that so I started investigating. I tried the following:

  • Testing the NAnt-target local on my machine – build successful
  • Manually running NUnit with all the same parameters as in the build-file, checking errorcode after run – errorcode 0 (success)
  • At least now I know it’s NUnit that is failing
  • For no good reason at all I’m just trying the failing test-assembly, leaving the other test-assemblies alone – errorcode 1 (1 failure)
  • I’m on to something
  • I add another test-assembly that doesn’t have failing tests in it – errorcode 0 (success)

It looks like NUnit forgets the result from the first test, and is just giving me the errorcode from the latest test-assembly provided!

Adding several test-assemblies to a NUnit project however does work correctly.

The solution

I didn’t want to make “static” NUnit project files, so I had to look for answers somewhere else and turned to the NUnit home pages. Earlier searches for errorcodes didn’t bring me to these pages at all, but I started looking around on the site and I found my way into the release notes.

I was using version 2.4.1 from May, and there was a 2.4.3 out from August. I downloaded it, updated my solutions tools folder, and….

It was fixed (the build failed… confused yet?!?)!

So, just to wrap it up: If you’ve been running NUnit 2.4.1 with more than one test-assembly, and your build server is happily saying the build is fine, don’t believe it!

Upgrade to a newer version and find out if your build is still fine .

]]> http://www.haugern.net/blog/nunit-swallowed-errorcodes/feed/ 0