Is there a "Who Broke the Build" plugin for Jenkins?

Question

Is there a plugin for Jenkins that can keep track of who keeps breaking builds over a period of time? Graphs would be good.

I'd like to bring (additional) shame upon the developers who keep checking in breaking changes.

Suzannasuzanne

Answer 1

We use the The CI Game plugin to bring shame upon others.

For live tracking, and if you can trust your fellow developers to follow suit, check out the Claim plugin.

UPDATE 2021. The answer is outdated. The page is 403 Forbidden and "CI Game" cannot be found.

Ijssel

Is "The Continuous Integration Game" plug in best used in a Java shop? We are mostly a .NET/Microsoft shop. Are there ways to track .NET metrics for anything besides breaking the build and successful builds? – Suzannasuzanne

Sorry, @JackAce, I'm not 100% sure how it would function in a .NET shop. I'd assume it would work just the same though. There are references to .NET shops using it, such as here. – Ijssel

We used it quite happily in a Perl shop. If you've got some kind of test harness, you should be able to convert its output to JUnit and then use Hudson's builtin test tracking quite easily. – Palanquin

@Suzannasuzanne did you ever try this in your .NET/Microsoft shop? I, too, an in a .NET/Microsoft shop using Jenkins but I've been hesitant to trying the CI Game plugin. There are some other Jenkins/.NET/Microsoft challenges, too. – Racer

@Racer I never did. Didn't seem like it was a good fit and they haven't done any updates since September 2012, so they probably won't help it play nice with .NET any time soon. – Suzannasuzanne

Answer 2

Just in case should you discover shaming people does not work too well, you could try pre-tested commits or gerrit or use the Github pull-request work flow, if those are available to you.

We use Github at work. Most of the developers cannot push to the main repo. They have to make a pull request and we have a requirement that pull requests are only merged if the developer can present test results that prove his code does not cause any regressions. We have almost eliminated problematic commits this way. I say almost, because nothing is 100% sure and since we are only human, sometimes a bug slips through.

Leatherman