Azure DevOps integration

Steps to construct your Azure pipeline for Gradle or Maven

1. In Azure DevOps, create or edit a Build Pipeline, and add a new Prepare Analysis Configuration task before your build task:
   • Select the SonarQube server endpoint you created in the Adding a new SonarQube Service Endpoint section.
   • Under Choose a way to run the analysis, select Integrate with Maven or Gradle.
   • Expand the Advanced section and replace the Additional Properties with the following snippet:
     • # Additional properties that will be passed to the scanner,
# Put one key=value per line, example:
# sonar.exclusions=**/*.bin
sonar.projectKey=YourProjectKey
2. Edit or add a new Maven or Gradle task
   • Under Code Analysis, check Run SonarQube or SonarCloud Analysis.
3. Add a new Publish quality gate Result on your build pipeline summary.
4. Under the Triggers tab of your pipeline, select Enable continuous integration, and choose all of the branches for which you want SonarQube analysis to run automatically.
5. Save your pipeline.

.yml example:

trigger:
- master # or the name of your main branch
- feature/*

steps:
 # Checkout the repository
 - checkout: self

 # Disable shallow fetch
  fetchDepth: 0

# Prepare Analysis Configuration task
- task: SonarQubePrepare@7
  inputs:
    SonarQube: '<YourSonarqubeServerEndpoint>'
    scannerMode: 'other'
    extraProperties: 'sonar.projectKey=<YourProjectKey>'

# Publish Quality Gate Result task
- task: SonarQubePublish@7
  inputs:
    pollingTimeoutSec: '300'

Steps to construct your Azure pipeline for .NET

1. In Azure DevOps, create or edit a Build Pipeline, and add a new Prepare Analysis Configuration task before your build task:
   • Select the SonarQube server endpoint you created in the Adding a new SonarQube Service Endpoint section.
   • Under Choose a way to run the analysis, select Integrate with MSBuild.
   • In the project key field, enter your project key.
2. Add a new Run Code Analysis task after your build task.
3. Add a new Publish quality gate Result on your build pipeline summary.
4. Under the Triggers tab of your pipeline, select Enable continuous integration, and choose all of the branches for which you want SonarQube analysis to run automatically.
5. Save your pipeline.

.yml example:

trigger:
- master # or the name of your main branch
- feature/*

steps:
 # Checkout the repository 
- checkout: self

 # Disable shallow fetch
  fetchDepth: 0

# Prepare Analysis Configuration task
- task: SonarQubePrepare@7
  inputs:
    SonarQube: '<YourSonarqubeServerEndpoint>'
    scannerMode: 'dotnet'
    projectKey: '<YourProjectKey>'

# Dotnet build task
- task: DotNetCoreCLI@2
  displayName: 'dotnet build'

# Run Code Analysis task
- task: SonarQubeAnalyze@7

# Publish Quality Gate Result task
- task: SonarQubePublish@7
  inputs:
    pollingTimeoutSec: '300'

.Net guides on the Sonar Community forum

We’ve prepared some guides on the Community Forum to help you with your .NET project.

.NET Configuration

• Configuration of WarningAsErrors for .NET build
• Investigating the performance of .NET analysis
• Managing technical debt with SonarQube and Azure DevOps 

.NET and Code coverage

• Generate reports for C# and VB.net
• How to find logs about importing code coverage
• Troubleshooting guide for .NET Code coverage import

Steps to construct your Azure pipeline for other languages

1. In Azure DevOps, create or edit a Build Pipeline, and add a new Prepare Analysis Configuration task before your build task:
   • Select the SonarQube server endpoint you created in the Adding a new SonarQube Service Endpoint section.
   • Under Choose a way to run the analysis, select Use standalone scanner.
   • Select the Manually provide configuration mode.
   • In the Project Key field, enter your project key.
2. Add a new Run Code Analysis task after your build task.
3. Add a new Publish quality gate Result on your build pipeline summary.
4. Under the Triggers tab of your pipeline, select Enable continuous integration, and choose all of the branches for which you want SonarQube analysis to run automatically.
5. Save your pipeline.

.yml example:

trigger:
- master # or the name of your main branch
- feature/*

steps:
 # Checkout the repository
 - checkout: self
 
 # Disable shallow fetch
   fetchDepth: 0

# Prepare Analysis Configuration task
- task: SonarQubePrepare@7
  inputs:
    SonarQube: '<YourSonarqubeServerEndpoint>'
    scannerMode: 'cli'
    configMode: 'manual'
    cliProjectKey: '<YourProjectKey>'

# Run Code Analysis task
- task: SonarQubeAnalyze@7
  inputs:
    jdkversion: 'JAVA_HOME_17_X64'

# Publish Quality Gate Result task
- task: SonarQubePublish@7
  inputs:
    pollingTimeoutSec: '300'

Steps to construct your Azure pipeline for C family projects

In your build pipeline, insert the following steps in the order they appear here. These steps can be interweaved with other steps of your build as long as the following order is followed. All steps have to be executed on the same agent.

1. Make the Build Wrapper available on the build agent: Download and unzip the Build Wrapper on the build agent (see the Prerequisites section of the C/C++/Objective-C page). The archive to download and decompress depends on the platform of the host. Please, note that:
   • For the Microsoft-hosted build agent, you will need to make the Build Wrapper available on the build agent every time (as part of the build pipeline). To accomplish this, you can add a PowerShell script task (for Windows) or a Bash task (for Linux and macOS) by inserting a Command Line task, and substituting the URL of your specific SonarQube instance into the download path below. 
     • Example of PowerShell commands on a Windows host:
       Invoke-WebRequest -Uri '<Your SonarQube URL>/static/cpp/build-wrapper-win-x86.zip' -OutFile 'build-wrapper.zip'
Expand-Archive -Path 'build-wrapper.zip' -DestinationPath '.'
     • Example of bash commands on a Linux host:
       curl '<Your SonarQube URL>/static/cpp/build-wrapper-linux-x86.zip' --output build-wrapper.zip
unzip build-wrapper.zip
     • Example of bash commands on a Linux ARM64 host:
       curl '<Your SonarQube URL>/static/cpp/build-wrapper-linux-aarch64.zip' --output build-wrapper.zip
unzip build-wrapper.zip
     • Example of bash commands on a macos host:
       curl '<Your SonarQube URL>/static/cpp/build-wrapper-macosx-x86.zip' --output build-wrapper.zip
unzip build-wrapper.zip
   • For the self-hosted build agent, you can either download it every time (using the same scripts) or only once (as part of the manual setup of your build agent).
2. Add a Prepare analysis configuration task and configure it as follow: Click on the Prepare analysis on SonarQube task to configure it:
   • Select the SonarQube Server.
   • In Choose the way to run the analysis, select standalone scanner (even if you build with Visual Studio/MSBuild).
   • In Advanced section > Additional properties, add the property sonar.cfamily.compile-commands with, as its value, the path to the compile_commands.json file inside the Build Wrapper output directory: sonar.cfamily.compile-commands=<output directory>/compile_commands.json
3. Add a Command Line task to run your build. For the analysis to happen, your build has to be run through a command line so that it can be wrapped-up by the build-wrapper. To do so,
   • Run Build wrapper executable. Pass in as the arguments: 
     1. The output directory configured in the previous task and 
     2. The command that runs a clean build of your project (not an incremental build):
        • Example of PowerShell commands on a Windows host with an MSBuild build:
          build-wrapper-win-x86/build-wrapper-win-x86-64.exe --out-dir <output directory> MSBuild.exe /t:Rebuild
        • Example of bash commands on a Linux host with a make build:
          build-wrapper-linux-x86/build-wrapper-linux-x86-64 --out-dir <output directory> make clean all
        • Example of bash commands on a Linux ARM64 host with a make build:
          build-wrapper-linux-aarch64/build-wrapper-linux-aarch64 --out-dir <output directory> make clean all
        • Example of bash commands on a macos host with a xcodebuild build:
          build-wrapper-macosx-x86/build-wrapper-macosx-x86 --out-dir <output directory> xcodebuild -project myproject.xcodeproj -configuration Release clean build

4. Add a Run code analysis task to run the code analysis and make the results available to SonarQube. Consider running this task right after the previous one as the build environment should not be significantly altered before running the analysis.
5. Add a Publish quality gate result task.

Once all this is done, you can trigger a build.

You must choose the correct image and adapt the correct wrapper depending on the agent OS. See the example below to configure the correct wrapper.

.yml example:

trigger:
- master # or the name of your main branch
- feature/*

steps:
- checkout: self
  # disable shallow fetch
  fetchDepth: 0

# Make Build Wrapper available
- task: Bash@3
  displayName: Download Build Wrapper
  inputs:
    targetType: inline
    script: |
      curl  '<SONARQUBE_HOST>/static/cpp/build-wrapper-linux-x86.zip' --output build-wrapper.zip
      unzip build-wrapper.zip

# Prepare Analysis Configuration task
- task: SonarQubePrepare@7
  inputs:
    SonarQube: '<YourSonarqubeServerEndpoint>'
    scannerMode: 'cli'
    configMode: 'manual'
    cliProjectKey: '<YourProjectKey>'
    extraProperties:  |
      "sonar.cfamily.compile-commands=bw_output/compile_commands.json"
# Command Line task to run your build.
- task: Bash@3
  displayName: Bash Script
  inputs:
    targetType: inline
    script: |
      ./build-wrapper-linux-x86/build-wrapper-linux-x86-64 --out-dir bw_output <Your build command>

# Run Code Analysis task
- task: SonarQubeAnalyze@7

# Publish Quality Gate Result task
- task: SonarQubePublish@7
  inputs:
    pollingTimeoutSec: '300'

Reporting quality gate statuses to pull requests in a monorepo setup is supported starting in Enterprise Edition.

In a monorepo setup, multiple SonarQube projects, each corresponding to a separate project within the monorepo, are all bound to the same Azure DevOps repository. You'll need to set up each SonarQube project that's part of a monorepo to report your quality gate status.

You need to set up projects that are part of a monorepo manually as shown in the Reporting your quality gate status in manually created or existing project section above. You also need to set the Enable monorepo support setting to true at Project Settings > General Settings > DevOps Platform Integration.

After setting your project settings, ensure the correct project is being analyzed by adjusting the Analysis Scope and pass your project names to the scanner. See the following sections for more information.

Ensuring the correct project is analyzed

You need to adjust the analysis scope to make sure SonarQube doesn't analyze code from other projects in your monorepo. To do this set up a Source File Inclusion for your project at Project Settings > Analysis Scope with a pattern that will only include files from the appropriate folder. For example, adding ./MyFolderName/**/* to your inclusions would only add code in the MyFolderName folder to your analysis. See the Analysis scope page for more information on setting your narrowing the focus of your analysis scope.

Passing project names to the scanner

Because of the nature of a monorepo, SonarQube scanners might read all project names of your monorepo as identical. To avoid having multiple projects with the same name, you need to pass the sonar.projectName parameter to the scanner. For example, if you're using the Maven scanner, you would pass mvn sonar:sonar -Dsonar.projectName=YourProjectName.

SonarQube can report your quality gate status to multiple DevOps platform instances. To do this, you need to create a configuration for each DevOps platform instance and assign that configuration to the appropriate projects.

• As part of Developer Edition, you can create one configuration for each DevOps platform.
• Starting in Enterprise Edition, you can create multiple configurations for each DevOps platform. 

When adding a quality gate status to your pull requests, individual issues will be linked to their SonarQube counterparts automatically. For this to work correctly, go to Administration > Configuration > General Settings > General > General to set the instance's Server base URL. Otherwise, the links will default to localhost.

These properties can be defined, should they be useful to your workflow:

Required properties

• cliSources
  • Note: Path to the root directory containing source files. This value is set to the sonar.sources SonarQube property.
  • Default: .
• configMode
  • Note: This property is required, but only needs to be modified if you specify the optional configFile property. Choose one of the options as your preferred configuration method. 
  • Options: 
    • file: Store configuration with my source code in sonar-project.properties
    • manual: Manually provide configuration mode
  • Default: file
• projectKey or cliProjectKey
  • Note: The project’s unique key and the name that will be displayed on the web interface. Allowed characters are letters, numbers, -, _, ., and :, with at least one non-digit. The cli prefix shall be used only while running in cli scanner mode.
  • Default: <yoursonarqubeusername_yourprojectname>
• scannerMode
  • Allowed values: dotnet (Integrate with .NET), other (Integrate with Maven or Gradle), cli (Use standalone scanner). 
  • Default value: dotnet
• SonarQube Server Endpoint
  • To create a SonarQube server endpoint, click the Manage link, create a new SonarQube Server Endpoint, and enter your server URL and token.
  • Default: The name of the Service connection you created in Azure DevOps.

Optional properties

• configFile
  • Note: The path to the file containing your SonarQube configuration. 
  • Default: sonar-project.properties
• extraProperties
  • Note: Additional properties to be passed to the scanner. Specify each key=value pair on a new line. See the Analysis parameters and Analysis scope pages for more detail on optional parameters. 
  • Note: Put one key=value per line; for example: sonar.exclusions=**/*.bin
• projectName or cliProjectName
  • Note: The name of the project that will be displayed on the web interface. The cli prefix shall be used only while running in cli scanner mode.
  • Default: For Maven projects: <name>; otherwise the projectKey. 
• projectVersion or cliProjectVersion
  • Note: The project version and the version of the project displayed on the web interface.  The cli prefix shall be used only while running in cli scanner mode. Do not use your build number as the projectVersion.
  • Default: For Maven projects: <description>; otherwise, “not provided”.
• msBuildVersion or cliVersion
  • Note: Optionally set these properties to override the embedded scanners with the specified versions. Use msBuildVersion to override the SonarScanner for .NET version, and cliVersion to override the SonarScanner CLI version.
  • Default: The active version of the SonarScanner for .NET or the SonarScanner CLI.

When caching the SonarScanner for .NET, add these inputs to your Prepare Analysis Configuration task to enable the SonarScanner to be cached. 

• msBuildVersion: When specifying your msBuildVersion, you must use the full version number. For example, use 8.0.3.99785, do not use 8.0.3. All of the available build numbers can be found here.
• projectKey: Your projectKey is equal to your sonar.ProjectKey.

Adapt this code sample using your preferred msBuildVersion and add it to your SonarQubePrepare@x task:

- task: SonarQubePrepare@7
  inputs:
    SonarQube: '<YourSonarqubeServerEndpoint>'
    scannerMode: 'dotnet'
    msBuildVersion: '<YourSonarScannerFullVersionNumber>'
    projectKey: '<YourProjectKey>'

Then define the cache task by adapting the Cache@2 task below:

- task: Cache@2
  displayName: Cache SonarScanner
  inputs:
    key: '"SonarScanner" | ".NET" | "$(Agent.OS)"'
    path: '$(Agent.ToolsDirectory)/SonarScanner .NET'

When caching the SonarScanner CLI, add these inputs to your Prepare Analysis Configuration task to enable the SonarScanner to be cached. 

• cliVersion: When specifying your cliVersion, you must use the full version number. For example, use 6.0.0.4432, do not use 6.0.0. All of the available build numbers can be found here.
• cliProjectKey: Your cliProjectKey is equal to your sonar.ProjectKey.

Adapt this code sample using your preferred msBuildVersion and add it to your SonarQubePrepare@x task:

- task: SonarQubePrepare@7
  inputs:
    SonarQube: '<YourSonarQubeServerEndpoint>'
    scannerMode: 'cli'
    configMode: 'manual'
    cliVersion: '<YourSonarScannerFullVersionNumber>'
    cliProjectKey: '<YourProjectKey>'
    cliSources: '.'

Then define the cache task by adapting the Cache@2 task below:

- task: Cache@2
  displayName: Cache SonarScanner
  inputs:
    key: '"SonarScanner" | "CLI" | "$(Agent.OS)"'
    path: '$(Agent.ToolsDirectory)/SonarScanner CLI'