Jenkins and Subversion and "Send separate e-mails to individuals who broke the build"

My current team wanted to use Jenkins' "Send separate e-mails to individuals who broke the build" feature. We use Subversion, and our Subversion usernames are not email addresses. And because my team members belong to different companies, we can't specify "Default user e-mail suffix" even if our Subversion usernames were the names of our email accounts.

For a while, I couldn't figure out how configure Jenkins to do what I want. I did a little googling and found out that Jenkins has a "People" page (for example, Apache's^* People page is: https://builds.apache.org/people/ ). Clicking on a person's User Id link takes you to their page. With our Jenkins configuration, a user's page has a "Configure" link on the right. Clicking that allows them to enter their name and a variety of other details, including Email address! That should allow me to use "Send separate e-mails to individuals who broke the build" the way my team asked.


* If you want to look at a big, vibrant Jenkins installation, check out the public Apache Jenkins machine: https://builds.apache.org/ Obviously it is read-only, but it has lots of projects, so there is usually something building, and you can see lots of examples of different statuses.

Jenkins Violations plugin quirk

Now that I got OpenCover working with Jenkins, I decided to go after fxCop. Here's the command-line I settled on:

"C:\Program Files (x86)\Microsoft Fxcop 10.0\fxcopcmd.exe" /oxsl:none /igc /f:OurApp.AssemblyToCover1.dll  /f:OurApp.AssemblyToCover2.dll /out:fxcop_results.xml /d:"c:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies"

The /oxsl: argument specifies no xsl transformation on the output (I'm using the Violations plugin which reads the native xml).

The /d: argument points to where System.Web.Mvc.dll lives, which one of our assemblies depends on.

As I mentioned before, I want to exclude several assemblies from analysis, so I specified the ones I want included by using /f: arguments (one per assembly).

NOTE: Getting the Violations plugin to work was easy once I realized one thing: the "XML filename pattern" must either be a filename pattern only (in which case the file will be in the Jenkins build project's workspace directory) or it must be in a directory below the Jenkins build project's workspace directory (for example results\fxCop*.xml) Absolute paths and relative paths starting with "..\" do not work.

I Got OpenCover to Work with Jenkins

As I mentioned before, a team that I am coaching is using Jenkins for CI. We wanted to automate code coverage measurements for the .Net code in specific assemblies of our solution. (Others are third-party or machine generated, so we don't have unit tests for them.) It took me longer than I would have liked, but I did get OpenCover running and generating reports as part of our Jenkins build.

One hurdle was that Jenkins seems to need to be run as user with administrator rights in order for OpenCover to work. So I created one and assigned it in the "Log On" tab.

In my Jenkins job, I opened "Add build step" and selected "Execute Windows batch command". In there, I gave the command line:

"C:\Program Files (x86)\OpenCover\OpenCover.Console.exe" -target:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe" -targetargs:"/testcontainer:E:\Jenkins\jobs\BuildOurApp\workspace\TRUNK\OurApp.UnitTests\bin\release\OurApp.UnitTests.dll" -filter:"+[OurApp.AssemblyToCover1]* +[OurApp.AssemblyToCover2]*" -register:user -mergebyhash -output:E:\Jenkins\jobs\BuildOurApp\workspace\FilteredCodeCoverage.xml

As an aside, I often have Jenkins jobs with several batch command sections. I found it annoying to scroll up and down and quickly find the one I was looking to edit. So I've started marking the top of each script:

REM   _      ___  _  __ _____  
REM  | |    |_ _|| |/ /| ____| 
REM  | |     | | | ' / |  _|   
REM  | |___  | | | . \ | |___  
REM  |_____||___||_|\_\|_____| 
REM                            
REM   _____  _   _  ___  ____  
REM  |_   _|| | | ||_ _|/ ___| 
REM    | |  | |_| | | | \___ \ 
REM    | |  |  _  | | |  ___) |
REM    |_|  |_| |_||___||____/ 

 
( http://patorjk.com/software/taag/ , "Standard" font, unchecked "Smush Letters Together" )


I have the HTML Publisher plugin installed, so I enabled it, clicked Add to add a row and specified:

E:\Jenkins\jobs\BuildOurApp\FilteredCodeCoverageReport 

index.htm

Code Coverage Report

as the arguments and it's all set! Now coverage is computed automatically and my team has a single URL for a summary report with drill-down details.

Trying to get .Net Metrics Computed and Displayed with Jenkins

I'm helping a .Net team stand up Jenkins as their CI server. The build steps we have so far are building a solution and running fxCop against the debug build. Using the Jenkins Violations Plugin, which supports fxCop, we can display a nice trend chart and have hot links to drill down and see the violations in context.


My next goal was to run metrics that my team agreed on, specifically Cyclomatic Complexity and Coupling. I was hopeful because Visual Studio 2010 can already compute them. But I found out that Visual Studio's code metrics can't be called on the command line. 


Fortunately, I found Visual Studio Code Metrics PowerTool 10.0 for that purpose. There's lots of information already out about using it: Jeff Bramwell has a blog post about the PowerTool and Cameron Skinner wrote one about it.


Unfortunately, the Violations Plugin doesn't support the xml output, and the PowerTool doesn't have an option to output to HTML. Fortunately, though, Skinner also wrote a post that provides an xslt and a .css file that will turn the results into HTML.

So my next step was to make a build step that runs a command-line tool to apply the transform. I couldn’t figure out or find enough documentation on msxsl.exe, but I found this CodeProject project and it works. (Anyhow, it would only take a few lines to write your own in C# because you can use calls from MSXML.)

Now I need to figure out how to use the HTML report in Jenkins. I'll investigate the Jenkins HTML Publisher Plugin.