We have seen in our previous post how to migrate SonarQube to a Windows service.
We actually made a new installation, without loosing our repository previously built with our version of SonarQube under Tomcat. We have checked that our projects, the results of previous analyzes, but also all existing configurations (plugins, Quality Profiles, etc..) were not lost.
Good. But what about Jenkins? Our Jenkins under Tomcat was working with the Tomcat version of SonarQube. And now it is working with SonarQube as a Windows service.
How to proceed? Here are the steps I followed.
Uninstall SonarQube from Tomcat
The first step was to remove SonarQube from the Tomcat webapps. For this, I simply:
- Open the directory where it is located – C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\webapps – on my laptop.
- Delete the file ‘Sonar.war’ and the sub-directory ‘Sonar’ in this folder.
Obviously, you have taken care to stop the Tomcat service before.
Launch an analysis with Jenkins under Tomcat
We will now attempt an analysis with Jenkins. This step is not mandatory, and I would say do not make sense: our current installation of Jenkins knows only the Tomcat version of SonarQube, that we have just delete.
But as we have seen in our previous post, SonarQube relies on its own repository, its own database schema and our current Jenkins knows how to feed it.
- Start the Tomcat service Windows.
- Launch an existing analysis with Jenkins, taking care previously to change the project version for this analysis.
I chose here an application (actually different applications) with ABAP code (SAP) and. in the next window, the one to configure my analysis in Jenkins, I’ll change the project version to increment this version to 2.0.
Do not forget to save the new setting before starting again this analysis.
Once finalized, we can see this new version 2.0 in the dashboard of SonarQube, as a service Windows…
… even though Jenkins still knows only the Tomcat version of SonarQube:
Once again, nothing wrong with that, since the results of the analysis are still stored in the repository of SonarQube, the ‘Sonar’ schema in the database (Oracle in my case).
Configure Jenkins with the new SonarQube (Windows service)
In the following window, we will look for the SonarQube configuration in Jenkins, and select the ‘Advanced…’ button.
Important note: You can see that I put the new url without the final slash. It will work, but I suggest you normalize this url by adding this slash.
Do not forget to save this new parameter with the ‘Save’ button at the bottom of the page.
Jenkins use the SonarQube Runner to execute an analysis. We have seen how to install it in this post ‘Install SonarQube – SonarQube Runner‘. On this occasion, we configured the SonarQube Runner with all the parameters necessary in the ‘sonar-runner.properties’.
In this file, we will indicate the new url of the SonarQube portal, as previously mentioned under Jenkins.
Note again the presence of the new slash at the end of url.
Start the analysis. When finalized, the analysis log in Jenkins (or ‘Console Output’) should display the following message:
ANALYSIS SUCCESSFUL, you can browse http://localhost:9000
Note: at the beginning of this log, you can see that the SonarQube ‘server’ is indicated with a slash at the end of the url, but this final message still appears without it.
By clicking this link, you will access to SonarQube portal and see the results of your analysis. Do not forget to start the corresponding Windows service before.
I experimented with different combinations of SonarQube and Jenkins installations, under Tomcat or as Windows services. I met some errors, and I will list two here, which I think might happen quite frequently. And you will understand why I insist on normalizing the slash at the end of the SonarQube url.
If you get the following error message:
The current batch process and the configured remote server do not share the same DB configuration. - Batch side: jdbc:oracle:thin:@localhost:1521/JPORA11 (sonar / *****) - Server side: check the configuration at http://localhost:9000/system
Verify that you have specified exactly the same url in the configuration of SonarQube in Jenkins and in the ‘sonar-runner.properties’ of the SonarQube Runner.
If you get the following error message:
Exception in thread "main" java.lang.IllegalStateException: Fail to request server version at org.sonar.runner.Bootstrapper.getServerVersion(Bootstrapper.java:73) ... caused by: java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) ... at java.net.URLConnection.getContent(URLConnection.java:748) at org.sonar.runner.Bootstrapper.remoteContent(Bootstrapper.java:125) at org.sonar.runner.Bootstrapper.getServerVersion(Bootstrapper.java:71) ... 4 more Finished: SUCCESS
First begin to check that you have started the Windows service for SonarQube. I think this error will be the most common (at least in my experience).
Recheck the urls and particularly the presence of the backslash at the end of it in the ‘sonar-runner.properties’ configuration SonarQube Runner.
The SonarQube Runner does not work correctly if this url does not have this final slash. But anyway, if you followed the steps in this post and you got an error, first check the url in both Jenkins and SonarQube Runner. I also met this case and it may be difficult and long to investigate before thinking about adding this slash.
The next post will be dedicated to the installation of Jenkins as a Windows service. And finally get rid of that good old Tomcat.
See you soon.