This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Jenkins can run a series of code analysis tools after each build, this will help you monitor the health of your solution.

Compiler Warnings

Ideally your solution will have no compiler warnings and you can have your solution fail to build if the any warnings appear. I know in the real world this isn’t always possible, so we can utilize Jenkins to make sure the number of warnings do not get out of hand.

This is accessed via the Jobs configuration page, for our Demo job we click Jenkins » Demo » Configure. You’ll find the “Scan for compiler warnings” at the bottom of this page under the “Post-Build Actions” section.

Configure

• Tick the “Scan for compiler warnings”
• Click the “Add” button under the “Scan console log” area
• Select MSBuild from the Parser drop down list
• Click the “Save” button

Now when you carry out a build, you’ll get a compiler warnings section as part of your build report.

Warnings report

Here we have no compiler warnings so I’ll commit a warning to show the information Jenkins tracks.

We now have 2 compiler warnings and we can drill down for more details by clicking the 2 warnings link.

We can continue drilling and find the actual source file and line number causing the warning.

Trending

As well as the low level details Jenkins also gives us a Compiler Warnings Trend graph.

Your mission is to reverse this trend and keep your compiler warnings low or preferably non-existent.

Tasks and To-dos

Another sign of Technical Debt is lots of To-dos, hack, and fix-me comments in your code. Lets use Jenkins to monitor these type of comments. For our Demo job we click Jenkins » Demo » Configure. You’ll find the “Scan workspace for open tasks” at the bottom of this page under the “Post-Build Actions” section.

Configure

• Tick the “Scan workspace for open tasks” check box
• In the “Files to scan” textbox enter: */.cs which scans all C Sharp files for these comments.
• In the “Tasks tags” High priority textbox enter: HACK, FIXME
• In the “Tasks tags” Normal priority textbox enter: TODO, TO-DO
• Tick the “Ignore case” check box
• Click the “Save” button

These task tags can be anything you or your team use to indicate work that needs to be carried out in your source. When we carry out a build, we’ll get a compiler warnings section as part of our build report.

Task Scanner Report

Here we have no tasks, I’ll commit a few To-dos and Hack comments to show the information Jenkins tracks.

We now have 3 open tasks and we can drill down for more details by clicking the 3 open tasks link.

As you can see depending on the priority of the open task we get different color bars to indicate they severity.

We can continue drilling and find the actual source file and line number of the tasks.

Trending

As well as the low level details Jenkins also gives us an Open Tasks Trend graph.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

After building your solution the next task you’ll want to automate is the running of your tests. Jenkins comes with a multitude of test plugins so whatever test framework you’re using chances are you’ll be covered. To show how easy it is to add tests to a build we’ll add NUnit to our demo solution and have Jenkins run the tests every time we commit a change to the source repository.

Test Project Structure

Structure of the demo project is:

Tools\NUnit\bin contains the NUnit framework and runner.

The DemoTest project references the nunit.framework.dll from this folder. This enables the solution to be checked out and run with out any pre-installation requirements. This work great for Jenkins but its also a great way to setup your solutions, if you need to move to a new machine or if you have a new starter you just check out the solution and its ready to build and run your tests.

Execute any test runner

The build step “Execute Windows batch command” works with any test runner that has a command line runner. We will use this method to run the NUnit command line test runner in the Demo project.

Use the Demo » Configure link to access the configuration page, under the Build section click the “Add build step” button.

Select the “Execute Windows batch command” to add a new build step.

Under the “Execute Windows batch command” section enter the command:

• Tools\nunit\bin\nunit-console.exe src\DemoTests\bin\Debug\DemoTests.dll

• Click the “Save” button

This command is telling Jenkins the location of the NUnit test runner (Tools\nunit\bin\nunit-console.exe) and the location of the test DLL to run against (src\DemoTests\bin\Debug\DemoTests.dll).

This command will now execute the NUnit test runner after every solution build.

Failing Tests

When a test fails Jenkins will fail the build and show a red ball for the status of the project.

Now we know the build has failed but we don’t want to start digging through the console output to find the details of the failing test. Lets introduce another Jenkins plugin which will show details of exactly which test failed and why.

Plugin Setup

Use the Demo » Configure link to access the Demo jobs configuration page, under the Post-Build Actions section.

• Tick the “Publish NUnit test result report” check box.

• Enter the output of the NUnit test runner: TestResult.xml

• Click the “Save” button.

Run a build again to see the NUnit test report.

• Click the Demo » Build Now link.

Of course the build has failed again but that’s what we want. This allows us to see NUnit test report. To view the report click on the failed build in the Build History.

We now have a Test Result area that is showing 1 failure in the DemoTests.ProgramTests.Add namespace. That’s certainly easier than digging through the console output. The benefits don’t end there, if you click on the Test Result link we will get a more detailed report.

Here we get a pretty report showing the full details of the failure. We can drill down for even more detail using the link DemoTests.ProgramTests.Add.

This gives the error message from the test, a stack trace, the filename of the failing test and even the line number. You can’t ask for much more than that but there is one more benefit we can eke out of our test runner and that is our test history.

Test History

Once you setup the Unit plugin, Jenkins will track all your test results. This is a great way to keep an eye on the general health of your project. I’ve added a few more tests and commits to the demo project to show how the test history works.

As you can see the Demo home page now has a “Test Result Trend” graph showing the initial failing test, followed by anther commit to fix the failure then another 4 tests that were added. The graph shows at a glance that our Demo project is getting healthier on every commit. This is the type of graph we want to see in our projects.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Unless you’re a glutton for punishment manually checking Jenkins after every build is going to become very old very quickly. Luckily Jenkins has several notification mechanisms to save you this manual task.

Email Notification

We can setup Jenkins to send an email notification whenever a build fails this save us having to check the server after every build, we can trust Jenkins to email us on failure. Jenkins will also send a notification email when the build returns to a working state.

Setting up email notification is a two-step process. First we give Jenkins details of the email server and second we set which email addresses to notify upon failure of a build.

Email Server Configuration

Email server configuration is done via the Configure System page. You get to the configuration page from the main Jenkins home page Manage Jenkins » Configure System. At the bottom of this page is the E-mail Notification section.

Chances are you’ll have a local SMTP server, if not you can use something like the Gmail SMTP server as shown here. Make sure you tick the “Test configuration by sending test e-mail” check box and then click the “Test Configuration” button to have Jenkins send you a test email, confirming your configuration is OK. Once you’ve successfully received an email don’t forget to click the “Save” button to save your changes.

Project Notification Email

Once you have the email server configured you can specify per project who to notify when a build fails. This is accessed via each Jobs configuration page, for our Demo job we click Jenkins » Demo » Configure. At the bottom of this page under the Post-Build Actions section is the E-mail Notification area.

• Tick the “E-mail Notification” checkbox.
• Enter a space-separated list of email address to notify when a build fails.
• Tick the “Send e-mail for every unstable build” checkbox.

If you really want to annoy the person who broke the build you can send them another email by ticking the “Send separate e-mails to individuals who broke the build” checkbox.

Finally don’t forget to click the “Save” button.

Unfortunately the only way to test this is working is to break the build, follow the instructions in section 6. Breaking the build to test email notification is working.

Your constant reminder

Email notification is great but I also like to have a constant reminder of the current build status. The best way I have found to do this on Windows is by using the Hudson Tray Tracker (read Jenkins Tray Tracker), which is available to download from http://code.google.com/p/hudson-tray-tracker/.

Once you download and install Hudson Tray Tracker you get a tray notification icon showing a constant reminder of the current build status. Initially the tray icon will be grey until you point it at a Jenkins build server.

• Right click on the tray icon to access the context menu.

• Click Settings to configure the software.

• Click the “Add server” button.

• Enter the URL and port of your Jenkins server.

• Click the “OK” button.

You will now see a list of projects on the Jenkins server.

Tick the Projects you would like to monitor. Here there is only our demo project but in reality you may have lots of Projects to monitor.

Once you have a server and projects setup, the tray icon will turn green to indicate a good build. That is assuming you have a working build. When the build breaks the icon will turn red and show a build failed message.

You can also use the software to open Jenkins on the build page of a Job by double clicking on the tray icon to open the list window.

Then double click on the Job your interested in. In this case double clicking on the Demo line will open up Jenkins on the Demo job page.

The teams constant reminder

A large screen in the development room can be a great way to give everyone on the team a highly visible, constant reminder of the current build status.

Jenkins has a Radiator View plugin that is designed specifically for this purpose.

https://wiki.jenkins-ci.org/display/JENKINS/Radiator+View+Plugin

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Last time we had a failing build with Jenkin’s showing a red ball to prove it. The first place to look when we have a failing build is the console output. You can get to the console output via the main menu on the left of your project page.

Console output

As the screenshot shows we get all the output from our build process and there is a lot of it! I’ve highlighted the actual problem which is the causing the build to fail, our missing dll.

This is the error your team mates will see when they check out and try to build your code.

Console “blindness”

When you first see the console output for your build it can be a little overwhelming, there is a lot of information packed into the output. Sometimes you look at all that information and you can’t see the wood for the trees, or the errors in all that output. I have seen people look at this output and they are blind to the errors.

Of course once you get used to looking at this output it becomes easier. To help you get over this initially a simple search to find all the errors listed on the page can really help. Simply search for the word “error” and your browser will help you see again.

You now have only a few places to concentrate your efforts in that sea of information.

To fix the problem we can simply add the missing dll and Jenkins will rebuild the solution and we’ll be back to green balls.

Next time we’ll look at the different ways to monitor our build and it’s failures.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Lets break the build to see how Jenkins reacts. I’ll add a DLL to the project then “forget” to add it to source control; unfortunately I see this problem a lot when new developers join the team.

I see red projects

As you can see Jenkins now shows a red ball next to the Demo project. Also notice the slightly cloudy weather icon indicating all is not well with our project.

How’s the weather?

Jenkins uses a weather metaphor to show at a glance how a project is doing.

	No recent builds failed
	1 out of the last 5 builds failed
	2 out of the last 5 builds failed
	3 out of the last 5 builds failed
	4 out of the last 5 builds failed
	5 out of the last 5 builds failed (Yeah I know the icon is no different to 4, go figure.)

«««< HEAD

======= »»»> breaking the build Obviously we want our projects to stay sunny and avoid the bad weather so next time we’ll discuss how to diagnose and fix a broken build.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

From the Project Demo page we created last time we can activate a Build at will.

Build Now

Click the “Build Now” link.

This tells Jenkins to build the Job we have just defined.

Build History

The Build History will show the Job running. Once the build is complete you should have your first successful build.

Clicking the Build History link (in this case 19-Feb-2012 00:10:39) will take you to the build page for the Demo Job.

Console Output

This page allows us to access all the information relevant to the build we just ran. The area we are interested in is the Console Output this shows all the programs that ran during the build.

Click the “Console Output” link.

This is the place to come whenever you are trying to debug a failing build. Everything you need to fix the problem will usually be shown on this page.

As you can see this was a successful build and we can see that:

• Jenkins created a workspace for the Job
• Ran a Subversion check out
  • Listed of all files updated
• Ran MSBuild
  • Shows all output from MSBuild
• Shows Success message

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

In Jenkins the definition of a build process is called a Job. Jobs are created using the main menu on the Jenkins home page. We’ll create a basic Job that will checkout our source and build the solution.

From the main Jenkins menu, Click the ‘New Job’ link.

You now see the New Job configuration page.

1. Set Job name to Demo.
2. Select the ‘Build a free-style software project’ radio button.
3. Click the ‘OK’ button.

Jenkins will now create the Job workspace on disk and redirect you to the job configuration page.

Next we’re going to checkout our solution from source control and build it. So we first need to give Jenkins details of our source control server.

Source Control

For the purpose of this demo we’ll use Subversion, mainly because this is the source control management software I use day to day. Subversion is a very popular open source choice for .NET.

Jenkins supports Subversion right out of the box but it also has support for all the major source control management systems. For example here are few which are popular for use with the .NET framework:

• Team Foundation Server Plugin - This plugin integrates Microsoft Team Foundation Server source control to Jenkins.
• Mercurial Plugin - This plugin integrates the Mercurial version control system with Jenkins.
• Git Plugin - This plugin allows use of Git as a build SCM. Git 1.3.3 or newer is required.
• Visual SourceSafe Plugin - This plugin integrates Jenkins with Microsoft Visual SourceSafe.

Visual SourceSafe, seriously? Maybe you’re being forced to use it at gunpoint? If not do yourself a favour and check out Subversion. VisualSVNServer is a very easy to install, administer and use on Windows best of all its free! There is also a great Subversion Plugin VisualSVN for Visual Studio that I highly recommend.

I have created a Subversion repository on GoogleCode that we’ll use to demo the build process from Jenkins. Lets setup our Job to grab the source code from this repository. This is done in the Source Code Management section of the configuration page.

1. Select the Subversion radio button.
2. Set the Repository URL to: https://jenkins-net-demo.googlecode.com/svn/trunk

Subversion Authentication

Unlike the demo repository used here, it’s more likely your source code repository requires authentication (if it doesn’t, you may want to think about securing it). If your repository does require authentication Jenkins will display and error message and ask for you to supply login credentials.

Click the “enter credential” link. You will now be shown the Subversion Authentication page.

Enter your authentication details and then click the “OK” button.

Subversion is now configured and we can move onto Build Triggers.

Build Triggers

We want to trigger a build every time our source code changes; we achieve this by creating a “Build Trigger” which polls our source code repository. When a change is detected a new build is triggered.

1. Under the Build Triggers section, tick the Poll SCM checkbox.
2. Enter “5 * * * *” in the Schedule text area, this translates to check for changes every 5 minutes.

As you can see from the help (which is available by clicking the icon) we can be extremely flexible in how often we check the source code repository for changes. Checking every 5 minutes is my default as I tend make lots of small commits and I want to know quickly if I’ve introduced a problem.

Finally we just need to tell Jenkins how to build the solution when changes are detected. This is done via the “Add build step” button under the Build section.

1. Click the “Add build step” button and select “Build a Visual Studio project or solution using MSBuild”.

2. This adds a “Build a Visual Studio project or solution using MSBuild.” area under the Build section.

1. Set “MsBuild Version” to V3.5 (The version we setup previously)
2. Set “MsBuild Build File” to the name of the demo solution: Jenkins-net-demo.sln
3. Click the “Save” button and you’ll be redirected to the Demo project page

Congratulations your first Jenkins Job is setup.

In my next post we’ll build it!

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

There are some important settings, that we need to configure before we get started building our first project.

Manage

On the main Jenkins menu, click the ‘Manage Jenkins’ link.

You will now see the Manage Jenkins page. Click the ‘Configure System’ link to get to the main configuration page.

MSBuild

We need to setup MSBuild to carry out the compilation and build of your .NET solutions. We can use any version of MSBuild you have installed on the Jenkins machine. As Windows 7 comes with version 3.5 of the .NET Framework pre installed I’ll demo that version here but obviously you can download, install and use any version of the .NET Framework.

Click the ‘Add MSBuild’ button.

Set the name and path to MSBuild:

1. Name: v3.5
2. Path to MSBuild: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
3. Click the ‘Save’ button

In my next post we’ll actually get to setup our first job!

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Plugins

To compile .NET and run our tests we need to add a few plugins to Jenkins. Thankfully Jenkins makes is very easy to find and install plugins. On the main Jenkins menu click the ‘Manage Jenkins’ link.

You will now see the Manage Jenkins page. Click the ‘Manage Plugins’ link.

You will now see a list of the currently installed plugins. Click the Available tab to see a list of all the Jenkins plugins, which are available to install.

As you can see Jenkins has a massive number of plugins. I encourage you to look through and play with the plugins they are really useful and the list is growing by the day.

Required Plugins

Without these required Plugins you will not be able to build and test .NET solutions. So you must at least install these Plugins for the rest of this guide to work.

Build Plugins

The Build Plugin we’ll be using is MSBuild this allows us to build a .NET solution.

• MSBuild Plugin - This plugin allows you to use MSBuild to build .NET projects.

Testing Plugins

You’ll need one of these depending on your chosen test framework.

• MSTest Plugin - This plugin converts MSTest TRX test reports into JUnit XML reports so it can be integrated with Jenkins JUnit features.
• NUnit Plugin - This plugin allows you to publish NUnit test results.
• xUnit Plugin - This plugin makes it possible to publish the test results of an execution of a testing tool in Jenkins.
• Gallio Plugin - This plugin makes it possible to publish Gallio/MbUnit test results.

Tick the check box next to each of the required Plugins and then click the ‘Download now and install after restart’ button.

Optional Plugins

These Plugins are optional but still recommend ranging from genuine productivity tools to just plain fun.

Jenkins Enhancements

• Green Balls - Changes Hudson to use green balls instead of blue for successful builds. Who doesn’t want Green Balls!
• Copy project link plugin - This plugin adds the “Copy project” link into left side panel in the main project page.
• Radiator View Plugin - Provides a job view displaying project status in a highly visible manner. This is ideal for displaying on a screen on the office wall as a form of Extreme Feedback Device.

Authentication

• Active Directory Plugin - With this plugin, you can configure Jenkins authenticates the username and the password through Active Directory.

NOTE: You can setup Authentication up without Active Directory but I’m guessing most of you already login via Active Directory so this Plugin saves you having to remember yet another password.

Code Analysis

• Task Scanner Plugin - This plugin scans the workspace files for open tasks and generates a trend report.
• Warnings Plugin - This plugin generates the trend report for compiler warnings in the console log or in log files.

Build Tools

• NAnt Plugin - This plugin allows for the execution of a NAnt build as a build step.
• PowerShell Plugin - Integrates with Windows PowerShell.

Fun, Fun, Fun

• ChuckNorris Plugin - Displays a picture of Chuck Norris (instead of Jenkins the butler) and a random Chuck Norris ‘The Programmer’ fact on each build page. Every build server needs a Chuck Norris, right?
• The Continuous Integration Game plugin - This plugin introduces a game where users get points on improving the builds. Although this is indeed a fun plugin it can help when first introducing Jenkins to your team, a little healthy competition never did anyone any harm.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Introduction

This is the first in a series of posts which I’ll be writing on using Jenkins to build .NET solutions. These posts will be as detailed as possible, probably too detailed in places.

Installing Jenkins

NOTE: Jenkins used to be known as ‘Hudson’ but when Oracle bought Sun there was a fall out between the then ‘Hudson’ developers and Oracle so they decided to fork the project and rename themselves Jenkins. Full details

I’m going to install and setup Jenkins on a freshly minted Windows 7 virtual machine although this process should work fine on other versions of Windows.

Go to the Jenkins home page: http://jenkins-ci.org/

Download

Rather than the generic .war file we’ll download the Windows native package, which saves as a few steps during installation. The latest windows package is available here:

http://mirrors.jenkins-ci.org/windows/latest

I’m using Internet Explorer here, which by default blocks the installer from downloading. Notice the warning message shown at the top of the browser window.

Click the message bar to get the download options context menu.

Select the Download File… menu option. You will now see the File Download dialog.

Click the Save button to download the installation zip file to your download folder. You will now see the Save As dialog again click the Save button to actually download the file.

In a short while you will see the Download complete dialog. Click the Open button to open the zipped installation file.

Internet Explorer Security may kick in and ask if you want to allow this operation. Click the Allow button to open the zip file.

Once the zip file is open, Click Extract all files from the menu.

You will now see the Extract zip file dialog, Click the Extract button to extract the files to the default location.

Phew! That’s the download complete.

Setup

Finally we can run the Setup program. Double click setup to run the program.

Windows will show a Security Warning to make sure you trust the publisher of this software. Click Run to begin the installation.

You will now see the Jenkins installation wizard. Click the Next button.

The wizard allows you to change the installation folder. Click Next to accept the default folder.

You are now at the final page of the setup wizard. Click the Install button and the installation will begin.

On Windows 7 the User Account Control may kick in to ask permission to run the installation. Click the Yes button to continue.

The installation wizard will now copy Jenkins onto your machine and display a message upon completion. Click the Finish button.

The install wizard will now open the Jenkins web page.

Congratulation Jenkins is now installed on your machine!