Sonarqube

The Issue We saw an issue with our SonarQube 10.3 Developer Edition (that is running as a Docker image hosted in Azure) when it was doing the analysis of a project that included Azure Bicep files. The Azure DevOps pipeline that triggered the SonarQube analysis was not failing, but within the SonarQube analysis step an error was reported in the task log INFO: Sensor IaC AzureResourceManager Sensor is restricted to changed files only INFO: 1 source file to be analyzed ##[error]ERROR: Cannot parse 'AzureServices/QueryPack.bicep:89:1' The Solution Turns out the problem was related to parsing Bicep files for App Insights Query packs. ...

The Problem We run our SonarQube instance in a Docker container hosted in an Azure Web App Service. Today, with no notice, it failed. We did the obvious, just tried to restart it and the startup process failed. Looking at the Azure Web App’s Log Stream we could see the following error repeated on each restart attempt 2023-09-27T15:30:00.797Z INFO - Starting multi-container app.. 2023-09-27T15:30:01.024Z INFO - Pulling image: sonarqube:10.1-developer 2023-09-27T15:30:02.100Z INFO - 10.1-developer Pulling from library/sonarqube 2023-09-27T15:30:02.291Z INFO - Digest: sha256:45e7cf02e037b00028d20556a91111f8ae8ae2b2803e516cb0665dd605a6d8b2 2023-09-27T15:30:02.292Z INFO - Status: Image is up to date for sonarqube:10.1-developer 2023-09-27T15:30:02.326Z INFO - Pull Image successful, Time taken: 0 Minutes and 1 Seconds 2023-09-27T15:30:02.344Z INFO - Starting container for site 2023-09-27T15:30:02.346Z INFO - docker run -d -p 8289:9000 --name bmsonarqubeprodwebsite_sonarqube_0_ec31111b -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=bmsonarqubeprodwebsite -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=bmsonarqubeprodwebsite.azurewebsites.net -e WEBSITE_INSTANCE_ID=6d27706a6b4eb56feec6ef57ab9b360923c5761cabb3fb52eb6fc5f4cdfbace3 -e WEBSITE_USE_DIAGNOSTIC_SERVER=False sonarqube:10.1-developer -Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmap=false 2023-09-27T15:30:02.347Z INFO - Logging is not enabled for this container. Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here. 2023-09-27T15:31:09 No new trace in the past 1 min(s). 2023-09-27T15:32:09 No new trace in the past 2 min(s). 2023-09-27T15:33:09 No new trace in the past 3 min(s). 2023-09-27T15:33:52.465Z ERROR - multi-container unit was not started successfully The Solution Something in the back of my mind, from when we ran an on-premises SonarQube instance, made me think of a corrupt ElasticSearch index. ...

This is another of those posts to remind me in the future. I searched the documentation for this answer for ages and found nothing, eventually getting the solution by asking on the SonarQube Forum When you link SonarQube into an Azure DevOps pipeline that is used from branch protection the success, or failure, of the PR branch analysis is shown as an optional PR Check The question was ‘how to do I make it a required check?’. Turns out the answer is to add an extra Azure DevOps branch policey status check for the ‘SonarQube/quality gate’ ...

Whilst adding SonarQube analysis to a large project I started getting memory errors during the analysis phase. The solution was to up the memory available to the SonarQube Scanner on the my build agent, not the memory on the SonarQube server as I had first thought. This is done with an environment variable as per the documentation, but how best to do this within our Azure DevOps build systems? The easiest way to set the environment variable `SONAR_SCANNER_OPTS` on every build agent is to just set it via a Azure Pipeline variable. This works because the build agent makes all pipeline variables available as environment variables at runtime. ...

We have been looking migrating some of our common .NET Core libraries into new NuGet packages and have taken the chance to change our build process to use Azure DevOps Multi-stage Pipelines. Whilst doing this I hit a problem getting SonarQube analysis working, the documentation I found was a little confusing. The Problem As part of the YAML pipeline re-design we were moving away from building Visual Studio SLN solution files, and swapping to .NET Core command line for the build and testing of .CSproj files. Historically we had used the SonarQube Build Tasks that can be found in the Azure DevOps Marketplace to control SonarQube Analysis. However, if we used these tasks in the new YAML pipeline we quickly found that the SonarQube analysis failed saying it could find no projects ##[error]No analysable projects were found. SonarQube analysis will not be performed. Check the build summary report for details. So I next swapped to using use the SonarScanner for .NET Core, assuming the issue was down to not using .NET Core commands. This gave YAML as follows,``` - task: DotNetCoreCLI@2 displayName: ‘Install Sonarscanner’ inputs: command: ‘custom’ custom: ’tool' arguments: ‘install –global dotnet-sonarscanner –version 4.9.0 ...

Problem I recently tripped myself up whist adding SonarQube analysis to a rather complex Azure DevOps build. The build has two VsTest steps, both were using the same folder for their test result files. When the first VsTest task ran it created the expected .TRX and .COVERAGE files and then published its results to Azure DevOps, but when the second VsTest task ran it over wrote this folder, deleting the files already present, before it generated and published it results. ...