*Grumble* CCNet

I have my new build server. So in the interest of time, at least I thought it was, I am installing CCNet on the new server. I'm even taking advantage of the opportunity to upgrade to 1.6. We were running 1.3. But really, CCNet, I need to give permissions to the AppPool user to update the files that you just installed? So far this is not going smoothly. I'm coming in this weekend to install Jenkins here too and have everything being built and tested by Jenkins come Monday. (♪♫ It'll be all right. ♪♫)

MSBuild and Jenkins

The available build steps that Jenkins has out of the box are Execute Windows batch command, Execute shell, Invoke ant, and invoke top-level Maven targets. I am pretty sure that I've used Jenkins to build using MSBuild, back when I was playing around with it last spring, so either I need a plug-in or need to do some Googling to see how others have done it by invoking a batch command.

So I go to Manage Jenkins > Manage Plug-ins and begin to peruse... Of course this can be very distracting when you begin to find all the incredible plug-ins readily available for Jenkins. (A lava lamp notifier!?! Awesome!) I find the MSBuild plug-in and also select the Fitnesse, NUnit and NCover plug-ins since I am pretty sure I'll be using those as well. I congratulate myself on my self-control for not also getting the Twitter notifier or Google Calendar Plug-in. I DID get the Chuck Norris plug-in, but only because Lisa Crispin told us we had to. I have to manually restart Jenkins again when the installations are complete.

I then go back to my initial build project in the dashboard and click 'Configure'. Now I have the option to create a build task with type ' Build a Visual Studio project or solution using MSBuild'. It asks for an MSBuild version but my only option is 'Default'. It also asks for the name of the MSBuild file - I input the name of the .sln solution file - and for any command line arguments - I leave those blank for now. As a post-build action I, of course, select 'Activate Chuck Norris'.
I save that, go back to my dashboard and schedule a build. Again I need to refresh to update teh status, wchi, to my dismay, is failed. When I click on the little number that shows that build #2 failed I am taken to a page where I can choose to see more details. Also Chuck Norris boasts that no statement can catch his exceptions...

I click on Console Output and see the error from the build: msbuild.exe is not recognized as an internal or external command. Hmm, I knew that I was getting away with having to do too little configuration for this thing. Let's go see where I need to set that path to MSBuild. I'm guessing in the management of the MSBuild Plug-in.
It is actually in Manage Jenkins > Configure System under a section for MSBuild. You have to provide the path there. I chose C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe though maybe I should have just selected the one under plain-ol' C:\Windows\Microsoft.NET\Framework. I'm going for broke.

I'll leave the MSBuild entry for my project as (DEfault) and see what happens. I may need to change it.

Turns out you do need to go back into your build configuration and select the version of MSBuild to run. I do this and WOOHOO... another failure. I'm missing a whole slew of other libraries that MSBuild looks for, but does not find. However, clearly MSBuild is taking control and attempting to build my solution. Only a matter of time and I will be checking out those other libraries and building these in some good sort of order... successfully.

Getting Jenkins to Check Out from Subversion

Jenkins comes with an SVN plug-in. When I went to Manage Jenkins > Manage Plugins it alerted me to an update to the SVN plug-in, which I updated. I checked the little box to have Jenkins re-start once the installation was complete, but it didn't. I had to go to the "Installed" tab of the plug-ins view and click the button there to re-start Jenkins.

Then I created a Jenkins project to just checkout some code from Subversion. After choosing to start a new build project I checked the Subversion radio control under Source Code Management, specified the URL to our SVN repository and set the Local module directory to '.\TestBuild' so I could evaluate where Jenkins puts things. Jenkins tried to immediately access the repository and I was warned that it could not access it because it appeared I was missing credentials. I added those credentials through the separate pop-up window that displayed. Jenkins then confirmed that it could access the repository. I left the other options there are their default values. I didn't add a build step nor any post-build options.

I went to the Dashboard and scheduled a build. The build indicator began to build indicating that the build was in progress. After a couple minutes it did not change, so I refreshed the dashboard and was shown that the last build was successful 2 minutes ago and only took 5.1 seconds. Having to refresh was no big deal, since the same thing happens with the CCNet web interface.

Now I just needed to confirm that Jenkins was able to check out the source code. In my Jenkins installation folder is a directory called jobs. Within that was a directory named the same as the name I gave my Jenkins job. Under that, along with some configuration files, are now two directories: builds and workspace. The builds directory has a directory named with a date-time stamp that is essentially empty. Under workspace is my TestBuild directory and under that the source code. I should have left the workspace path as '.'.

So now I'm moving on to creating a build step to have Jenkins use MSBuild to build my project.

Installing Jenkins for Windows 7

Here is all the "trouble" I had to go through (since my last blog post, mind you) to get the Jenkins server up and running on my local machine.

1) Download native Windows package from jenkins-ci.org. (jenkins 1.436)
2) Run setup to install to C:\Program Files (x86)\Jenkins\
3) Everything else went automatically to start the server on port 8080; however, when the browser came up directed at http://localhost:8080 it got a 404. Turns out the web service just took a little extra time to start up and refreshing the browser showed the Jenkins dashboard.

Automating With Jenkins

I'm re-configuring our project build to use Jenkins instead of CruiseControl. I'm sure the entire world is bound to find this extremely fascinating, so I am blogging about it. There are a number of little reasons for this, but mostly it's simply because I find CCNet to bed tired and old and Jenkins to ben the new hotness. Actually, I am just up for learning something new, and since we need to create a new build environment anyway, I figured I'd take a shot at using Jenkins.

A bit about the project

It is a .Net project that uses the .Net 4.0 framework with a WPF client that communicates to a WCF Web Service that communicates with a WCF Windows Service. It's not a bad architecture, though probably not the BEST architecture. It is definitely not an architecture that is easily testable. It uses SQL Server 2008 as the data store and our version control is SVN.

Our old build environment, like I said, uses CruiseControl.Net. It was what we were using for previous projects, and was adequate for simply doing our build. Now that we are getting into automating our unit and acceptance tests, however, its age is showing. We are generally building for x64 processors and the build environment is an x86 processor. SQL Server 2005 is installed, but not 2008. The version of NCover and NUnit that are installed are outdated and NUnit 2.4.8 will not handle assemblies written for .Net 4.0.

Onward!

So while our IT department is building me a virtual machine with the build environment that I want, I am going to try to and get an automated build running on my laptop with Jenkins. Wish me luck.