I’ve been setting up a Jenkins CI server for the last few days and I’m getting to the last few steps where I work out all the wrinkles and make everything play nicely together. The issue I’m fighting with at the moment I’m going to call SonarQube analysis SVN blame failure for the want of a better description.

Almost the whole build process will work fine, Jenkins builds and tests the software SonarQube rebuilds and analyses the code and then right at the end it falls over in a big heap with this error message:

[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.6:sonar (default-cli) on project FOO: The svn blame command [svn blame --xml --non-interactive -x -w src/main/java/com/example/foo/SomeClass.java] failed: svn: E155036: Please see the 'svn upgrade' command
[ERROR] svn: E155036: The working copy at '/var/lib/jenkins/jobs/FOO/workspace/src/main/java/com/example/foo'
[ERROR] is too old (format 8) to work with client version '1.8.8 (r1568071)' (expects format 31). You need to upgrade the working copy first.
[ERROR] -> [Help 1]

There are a couple of stack traces as well but they don’t really seem to add any more detail. On the face of it this seems like a perfectly clear failure, the code has been checked out of Subversion in a very old format. The problem is this literally just came from the Subversion server using the latest SVN client so what gives?

SonarQube Analysis SVN Blame Solution One

This is what I would call the correct solution to the problem but it’ll only work if you have a Subversion 1.8 server and clients available. I had assumed that Jenkins would pick the best / latest available version of SVN for the checkout but it turns out that it actually defaults to the oldest version (perhaps for compatibility). To correct this go into Manage Jenkins > Configure System and then change the version of SVN Jenkins is using:

It’s likely at this point that you will have tried and failed to perform a build and you’ll have a populated workspace with a .svn directory. By default SVN won’t upgrade this workspace to the new version. You can either fiddle around trying to get an “svn upgrade” command to work or a much simpler option is just to open the project in Jenkins and then wipeout the workspace. On the next build the workspace will be recreated with the newer version of SVN.

SonarQube Analysis SVN Blame Solution Two

If you can’t upgrade the version of SVN you are using you can switch off blaming in SonarQube. Under Settings > SCM there is a setting called “Disable the SCM Sensor” which if set to true will stop SonarQube trying to use the SVN blame command. Note that in previous versions of SonarQube this setting was called “Activation of this SCM Activity Plugin” and it had to be set to false.