0

We have big-old Java project with a lot of legacy code. Now we have code conventions and Checkstyle rules to check it.

We want to configure Jenkins job, which runs after every commit to SVN, to check, if modified/added lines are not violate any our Checkstyle rule.

It's not an option to check whole project, because of legacy code. Also we can't just reformat all the code, because then it will be difficult to determine who changed a particular line and why.

The approach we consider - to make diff between previous and current Checkstyle report, and see, if there are new violations.

The question is - how we can get access to the previous Checkstyle report in Jenkins?

Or how to configure checkstyle to fail build only if there are new violations?

And may be there are ready-made solutions for such check?

dds
  • 2,335
  • 1
  • 31
  • 45
  • In a simliar situation we called a code freeze, reformatted all code using an automatic formatter, and checked in the changed format. Now we can see who changed what by comparing against either the file version before the reformat (for very old changes) or against the file version after the reformat (for newer changes). This worked very well for everybody. – barfuin Feb 12 '13 at 14:05

4 Answers4

1

This is a bit round-about, but if you set up a Sonar instance to analyze your project, you can query violations data programmatically through it's remote access API. You know the violations count in the legacy code (presumably, that number won't change frequently). That's your baseline - you don't want the count to go higher than that.

So inside your CI job, you could add a script at the end that calls Sonar to get the count of violations at each of the severity levels you care about (Blocker, Critical, etc), and fail the build if the current count exceeds the threshold/benchmark.

Sonar is pretty awesome overall, especially for projects with lots of legacy code, 'cuz you can drill down and figure out where your riskiest areas are. They've got a public instance running if you haven't checked it out yet.

Sarah
  • 53
  • 1
  • 4
1

The solution was to make a bash script which make diff with previous checkstyle report and fails build if there are new violations.

dds
  • 2,335
  • 1
  • 31
  • 45
0

Have you checked on Checkstyle Plugin that is available for jenkins? It will generate reports for each commit and you could compare the results for each change. Each commit will trigger a new build and a new report will be generated at the end.

Shiva Kumar
  • 3,111
  • 1
  • 26
  • 34
  • Of course I checked it, but the question is - how we can get access to the Checkstyle report from previous biuld? – dds Feb 11 '13 at 08:29
  • Why do you want to make a diff when the plugin itself will show you the new violations? – Shiva Kumar Feb 11 '13 at 08:56
  • Could you tell me, how to configure checkstyle plugin to fail build only if there are new violations? Because now we have a lot of it, and build failures regardless of new violations. – dds Feb 11 '13 at 10:54
  • Usually in the advanced configurations of such plugins, you will have option to specify the threshold. If the build exceeds this threshold, either you can fail the build or make it unstable. If you are saying the build is failing regardless of new violations, I am wondering if you have set any other property which makes the build fail. What do you see in the console output the reason for build failure? – Shiva Kumar Feb 11 '13 at 12:02
  • Build failures because of checkstyle violations: Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default-cli) on project mms-interop: You have 1923 Checkstyle violations. – dds Feb 12 '13 at 02:07
  • I am not very conversant with maven configuration. Can you check [this question](http://stackoverflow.com/questions/11106767/maven-checkstylecheck-not-working) and its answer and see if it works for you? It could be configuration problem that is causing the build to fail. – Shiva Kumar Feb 12 '13 at 05:27
  • So the solution was to configure Status thresholds for Checkstyle Plugin so it fails build if there are new violations, and to trigger build after every commit. – dds Feb 18 '13 at 07:43
  • Actually the solution with Checkstyle Plugin was not suitable because it fails every build after commit code with violations. – dds Mar 29 '13 at 05:20
0

Have you checked on Checkstyle Plugin that is available for jenkins? It will generate reports for each commit and you could compare the results for each change. Each commit will trigger a new build and a new report will be generated at the end.Shiva Kumar

Of course I checked it, but the question is - how we can get access to the Checkstyle report from previous biuld?

May I also suggest the Static Code Analysis Plug-ins. This will show you the trend line of Checkstyle issues as a nice graph. You can also use this with the CI Game plugin that will award points for fixing Checkstyle issues, and deduct points for causing more checkstyle issues.

I've found the CI Game plugin to work really well -- especially if you get your developers involved in a bit of a contest:

We're adding a little something to this month's contest. As you all know, first prize is a Cadillac Eldorado. Anybody want to see second prize? (Holds up prize) Second prize is a set of steak knives. Third prize is you're fired.

Alec Baldwin as Blake in Glengarry Glen Ross

It's amazing how fast those Checkstyle issues get fixed when you turn it into a fun game.

Community
  • 1
  • 1
David W.
  • 105,218
  • 39
  • 216
  • 337
  • I know about this plugins, they are nice, but our main goal is to check new commits for violations, not to fix the old violations. – dds Feb 12 '13 at 02:10
  • All the Checkstyle plugin does is parse the resulting XML file that the CheckStyle task generates. Instead of doing this in Jenkins, you need to munge your Checkstyle task in the build.xml file. The CheckStyle ant task takes a fileset, so it is possible to build a fileset based upon the changed files, and then run your Checkstyle task on just those. Then, Jenkins will do what you want. You might be able to use the [Date](http://ant.apache.org/manual/Types/selectors.html#dateselect). I'll have to play around with it a bit to figure it out. I'll append my answer if I figure something out. – David W. Feb 12 '13 at 15:08
  • BTW, we use Maven, not ant. But the problem is - how to persist "resulting XML file that the CheckStyle task generates" to compare with later. – dds Feb 13 '13 at 02:10
  • I'm not sure how Maven with Checkstyle works, but the Checketyle plugin in Jenkins is a _post-build_ process with Jenkins. Jenkins doesn't run Checkstyle -- you're responsible to make sure your project generates a Checkstyle XML file. What you do is specify in the post build procedure that 1). You want to generate a Checkstyle analysis, and 2). where that Checkstyle XML file your build generated is located. – David W. Feb 13 '13 at 15:30
  • I just looked up the Maven plugin, and this is one of the areas where Maven ...what's the technical term? ...oh yeah... sucks. Maven is okay as long as you follow the straight and narrow. However, if you want to do something a wee bit different like running a Checkstyle on a limited subset of files, you're in trouble. In cases like this, I find myself running the Ant Maven task to do what I need to do. If you haven't already, take a look at the Jenkins Checkstyle plugin and see how it works. – David W. Feb 13 '13 at 15:35