During installation and setting up a SonarQube server for usage in an Azure DevOps Build I found some things that I didn’t remember from previous installation, so I wanted to log that in this post, so the next time I have somewhere to find these things in one place.
For installation on an Azure environment I used the same Azure QuickStart ARM template I used before. Somehow, each time I need this template, something has changed underneath and I get to fix the template. This time the download URL for the SonarQube installer was changed as well as a new version got released. This has now been included in the template: because it is open source, I could find the places that needed to be updated and send in a pull request to Microsoft with the fix. I love open source! Such a pleasure to find an issue, look at the code and present a fix to the repository maintainer!
You can follow the usual steps from the ARM template: download and install the Java Development Kit on the SonarQube server, restart the SonarQube service and you’re up and running with the server side.
There are a couple of things that you need to think of when starting an installation yourself. The ARM template is already a great help in it, but you need to think of some other things. Those are mostly client side, so on the agent.
As noted before, the template uses a self signed certificate, which will not work with Azure DevOps: the tasks from the marketplace need a valid certificate that it trusts for the connection with the server. Therefore you need to provide a valid certificate and setup a DNS entry to match the URL in the certificate.
Go to the marketplace and download or request installation in your Azure DevOps subscription.
This was a gotcha that I forgot this time: the
Run Analysis Task has a demand requirement that it needs Java (specifically the Java Runtime Environment 8.0) on the agent. This also means that you cannot run it on a hosted agent : those do not have the JRE installed! Only the JDK is installed, which doesn’t add support for the
java demand. I raised an issue on the hosted agent with a request for it.
When you have a new agent you could install Visual Studio Community edition on it, that will provide you with the
msbuild capability on the agent. This does not give you the tools to run the unit tests on the server, which is needed for the
Run unit test task, which will provide SonarQube with the necessary information it needs to do, well basically, anything! You can install a licensed Visual Studio Enterprise on it, but then you need to update that license every once in a while. You probably don’t want that, because of the occasional error it will give you, for which you need to login to the server.
To help fix this, you can use the Visual Studio Test Platform Installer task to install all the tools VSTest needs to run.
Out of the box, SonarQube can scan your CSS files for issues with over 180 available rules. To do this, the agent needs to have Node.js installed. This is already available on a hosted agent, but you cannot use that yet because of the dependency on JRE!
Currently there is an issue on SonarQube with larger solutions or CSS files. The process seems to run out of memory somewhere. In the Azure DevOps Build log, you’ll see these as the last steps being logged:
INFO: Quality profile for cs: Sonar way INFO: Quality profile for css: Sonar way INFO: Quality profile for js: Sonar way INFO: Quality profile for xml: Sonar way INFO: Sensor SonarCSS Metrics [cssfamily] WARNING: WARN: Metric 'comment_lines_data' is deprecated. Provided value is ignored. INFO: Sensor SonarCSS Metrics [cssfamily] (done) | time=1937ms INFO: Sensor SonarCSS Rules [cssfamily]
For now the recommended fix is: do not use the CSS analysis, which isn’t great, but better then the alternative: currently the
Run Analysis Task just hangs until the maximum runtime of your build has been reached. Al that time, your build server will run at 100% CPU (if you have 1 CPU available, 2 CPU’s got me 50% utilization)!
It took me quite some searching around to find this one, so it’s good to document it here.
The current fix is to start the analysis task with a parameter that redirects the CSS files to a non-existing analyzer:
d:sonar.css.file.suffixes=.foo or do that globally for your entire SonarQube server via the settings on the CSS analysis there (which would be easier if you have multiple projects with this issue).