SonarQube - The Complete Guide

Murtuza RangwalaMurtuza Rangwala
17 min read

Table of contents

What is SonarQube?

SonarQube is an open-source platform developed by SonarSource used for continuous inspection of code quality. It performs static code analysis to detect bugs, vulnerabilities, and code smells in multiple programming languages. SonarQube integrates with CI/CD pipelines to ensure clean, maintainable, and secure code.

Why do we use SonarQube?

  1. Code Quality Assurance: Identifies bugs, code smells, and security vulnerabilities.

  2. Continuous Integration: Integrates with CI/CD pipelines for automatic code analysis.

  3. Multi-language Support: Supports over 25 programming languages like Java, JavaScript, C#, Python, etc.

  4. Technical Debt Management: Provides metrics to track and reduce technical debt.

  5. Security Analysis: Detects security issues and suggests remediations.

  6. Customizable Rules: Allows teams to customize rules and quality profiles as per project needs.

Alternatives to SonarQube

  • CodeClimate: Focuses on maintainability and test coverage.

  • Codacy: Provides static analysis, security checks, and code reviews.

  • Checkmarx: Emphasizes security vulnerabilities detection.

  • Fortify: Enterprise-level static and dynamic security testing.

  • Veracode: Advanced application security testing platform.

SonarQube Editions and Their Differences

  1. Community Edition (Free):

    • Supports static code analysis for 15+ languages.

    • Basic security checks.

    • No commercial support.

  2. Developer Edition:

    • Adds vulnerability detection.

    • Branch analysis.

    • Adds more language support.

  3. Enterprise Edition:

    • Portfolio and governance management.

    • Reports and dashboards.

    • Advanced security checks.

  4. Data Center Edition:

    • Designed for large-scale enterprises.

    • High availability and horizontal scalability.

Benefits of SonarQube

  • Improved Code Quality: Provides real-time feedback and guidance.

  • Enhanced Security: Identifies security vulnerabilities early in development.

  • Automation: Seamless CI/CD integration ensures continuous inspection.

  • Actionable Insights: Offers metrics and trends to manage technical debt.

  • Scalability: Supports multiple languages and large projects.

  • Customizable: Adapts rules and quality gates to project needs.

Key Concepts DevOps People Should Know About SonarQube

  1. Quality Gates: Define the pass/fail criteria for code quality checks.

  2. Quality Profiles: Set rules for specific languages.

  3. Technical Debt: Tracks the effort needed to fix issues.

  4. Metrics: Provides insights into code complexity, duplication, and security.

  5. Integration: Works with Jenkins, GitLab, GitHub Actions, Azure DevOps, etc.

  6. Reports: Generates reports for audits and compliance.

**SonarQube Server 10.8 | Official Documentation**

SonarQube Prerequisites (Hardware & Software)

Hardware Requirements:

  • Small scale (up to 100K LOC): 2 cores, 4 GB RAM, 10 GB disk space

  • Medium scale (100K–500K LOC): 4 cores, 8 GB RAM, 20 GB disk space

  • Large scale (500K+ LOC): 8+ cores, 16+ GB RAM, 50+ GB disk space

  • Disk: SSD recommended

Software Requirements:

  • Java 17 (OpenJDK or Oracle JDK)

  • Database:

    • PostgreSQL (10 or later) — recommended

    • Microsoft SQL Server (2016 or later)

    • Oracle (12c or later) — paid

  • H2 database (default, for testing only — not for production)

OS Compatibility:

  • Linux: Ubuntu, CentOS, Red Hat (64-bit)

  • Windows: Windows Server 2019 or later (64-bit)

  • macOS: Monterey or later (for dev use only)

Network Requirements:

  • Port 9000 (for SonarQube's web interface)

  • Ensure firewall allows traffic on port 9000

Additional Tools for CI/CD:

  • Git (version control)

  • Build tools:

    • Maven (Java projects)

    • .NET SDK (C# projects)

    • Node.js/npm (JavaScript/Angular projects)

How to install SonarQube(Linux/Ubuntu)?

Step 1: Update the System

sudo apt update
sudo apt upgrade

Step 2: Install Java (OpenJDK 17) (If not already installed)

sudo apt install openjdk-17-jdk
java -version

Step 3: Create a SonarQube User

Create a non-root user to run SonarQube securely:

sudo adduser --system --no-create-home --group --disabled-login sonarqube

Step 4: Download and Install SonarQube

1. Go to /opt — the standard directory for optional software:

cd /opt

2. Download the SonarQube Community Edition:

wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-10.3.0.82913.zip

OR Download Manually from here => SonarQube Download | Community Build | Sonar

3. Install unzip if not installed:

sudo apt install unzip

4. Unzip the SonarQube package:

sudo unzip sonarqube-10.3.0.82913.zip

5. Rename the directory for simplicity:

sudo mv sonarqube-10.3.0.82913 sonarqube

6. Set the correct permissions:

sudo chown -R sonarqube:sonarqube /opt/sonarqube

Step 5: Configure SonarQube

Edit the SonarQube configuration file:

sudo nano /opt/sonarqube/conf/sonar.properties

For now, we’ll use the built-in H2 database (default for testing). You can configure PostgreSQL later if needed.

Ensure the following line is enabled for web access: sonar.web.port=9000

Step 6: Set Up SonarQube as a Service

Create a new systemd service file:

sudo nano /etc/systemd/system/sonarqube.service

Add the following configuration:

[Unit]

Description=SonarQube service

After=syslog.target network.target


[Service]

Type=forking

User=sonarqube

Group=sonarqube

ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start

ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop

LimitNOFILE=65536

Restart=always


[Install]

WantedBy=multi-user.target

Reload the systemd configuration:

sudo systemctl daemon-reload

Step 7: Adjust System Limits

SonarQube requires higher limits for file descriptors and virtual memory:

1. Update kernel limits temporarily:

sudo sysctl -w vm.max_map_count=524288
sudo sysctl -w fs.file-max=131072

2. Persist the settings by adding them to /etc/sysctl.conf:

sudo nano /etc/sysctl.conf

Add these lines:

vm.max_map_count=524288
fs.file-max=131072

Apply the changes:

sudo sysctl --system

Step 8: Start SonarQube

Enable SonarQube to start at boot:

sudo systemctl enable sonarqube

Start the SonarQube service:

sudo systemctl start sonarqube

Check the service status:

sudo systemctl status sonarqube

Step 9: Access SonarQube

By default, SonarQube runs on port 9000.

Open your browser and go to:

http://your-server-ip:9000

Default credentials:

Username: admin

Password: admin

You’ll be prompted to change the password on the first login.

Installation of SonarQube in Windows

Step 1: Prerequisites

  1. Install Java 17

    • SonarQube requires Java 17 (OpenJDK or Oracle JDK).

  • Download OpenJDK 17 from Adoptium.

  • Install it and set up the environment variables:

Set JAVA_HOME:

setx JAVA_HOME "C:\Program Files\Java\jdk-17"

Add Java to PATH:

setx PATH "%PATH%;%JAVA_HOME%\bin"

Verify installation: java -version

  1. (Optional) Install PostgreSQL
    SonarQube comes with an embedded H2 database, but for production use, we should use PostgreSQL.
    Download PostgreSQL from here.

Create a database for SonarQube:

CREATE DATABASE sonarqube;

CREATE USER sonar WITH PASSWORD 'sonar';

ALTER ROLE sonar SET client_encoding TO 'utf8';

ALTER ROLE sonar SET default_transaction_isolation TO 'read committed';

ALTER ROLE sonar SET timezone TO 'UTC';

GRANT ALL PRIVILEGES ON DATABASE sonarqube TO sonar;

Step 2: Download SonarQube

Extract the ZIP file to a directory like: C:\SonarQube\

Step 3: Configure SonarQube (Optional)(Skip if using the default H2 database)

If you want to connect to PostgreSQL:

Open this file: C:\SonarQube\conf\sonar.properties

Update the PostgreSQL settings:

sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
sonar.jdbc.url=jdbc:postgresql://localhost:5432/sonarqube

Change the default port (if needed):

sonar.web.port=9000

Step 4: Start SonarQube

  1. Open Command Prompt as Administrator.

Navigate to the bin directory:
cd C:\SonarQube\bin\windows-x86-64

Start SonarQube (without installing it as a service):
StartSonar.bat

**Wait for the log to show:
**SonarQube is up

Access SonarQube in your browser:
http://localhost:9000

  1. Login credentials:

    • Username: admin

    • Password: admin

Step 5: Stop SonarQube

To stop the SonarQube instance, either:

  • Close the terminal running the StartSonar.bat.

  • Or press Ctrl + C in the terminal.

Step 6: Install SonarScanner (Optional – For Analyzing Projects)

To analyze a project using SonarQube, install SonarScanner:

  1. Download SonarScanner from here.

Extract the ZIP file to:
C:\SonarScanner\

Set environment variables:

setx SONAR_SCANNER_HOME "C:\SonarScanner\bin"
setx PATH "%PATH%;%SONAR_SCANNER_HOME%"

Verify installation:
sonar-scanner -h

Step 7: Run a Sample Code Analysis

In your project directory, create a file named sonar-project.properties:

sonar.projectKey=my_project
sonar.host.url=http://localhost:9000
sonar.login=admin
sonar.password=admin
sonar.sources=.

Run the scanner:

sonar-scanner

View the results in SonarQube’s UI: http://localhost:9000

Step 8: Run SonarQube as a Windows Service (Optional)

If you want SonarQube to run automatically on startup:

Instead of Wrapper.exe, we need to use the SonarService.bat script:

Open Command Prompt as Administrator.

Navigate to your SonarQube bin folder:

cd C:\SonarQube\bin\windows-x86-64

Install SonarQube as a service:
SonarService.bat install

Start the service:
net start SonarQube

If there's an error, check the logs in C:\SonarQube\logs\sonar.log.

Verify the service

Check if SonarQube is running:
sc query SonarQube

Or use the Task Manager → Services tab → Look for SonarQube.

(Optional) Auto-start the service

If you want SonarQube to start automatically with Windows:

  1. Open Services (services.msc).

  2. Find SonarQube → Right-click → Properties.

  3. Set Startup type to Automatic.

  4. Click Apply → OK.

Troubleshooting

Port 9000 already in use:
Change the port in sonar.properties:
sonar.web.port=9001

Java errors:
**Ensure you’ve installed Java 17 and set the correct JAVA_HOME:
java -version

echo %JAVA_HOME%

Memory issues (max virtual memory error):
Run this in Admin Command Prompt:
wmic computersystem set AutomaticManagedPagefile=True

Global SonarQube Configuration (sonar-scanner.properties)

Apart from project-level configs, there’s a global config file used by SonarScanner called sonar-scanner.properties.

Where to find it (Location):

  • Linux: /etc/sonar-scanner/sonar-scanner.properties

  • Windows: C:\sonar-scanner\conf\sonar-scanner.properties

  • Inside Docker: /opt/sonar-scanner/conf/sonar-scanner.properties

What does it do?

  • Stores default configs for all projects, so you don’t have to repeat them in each sonar-project.properties file.

  • Useful for setting the default SonarQube server URL, authentication token, etc.

Example:

# SonarQube server URL

sonar.host.url=http://localhost:9000

# Authentication token

sonar.token=your_sonar_token

# Default project settings

sonar.sourceEncoding=UTF-8

sonar.language=java

How to use it:

  • If you have this global config set up, you can run the scanner without specifying these options each time: sonar-scanner

The scanner will automatically pull configs from the global file.

SonarQube Integration with Maven

Prerequisites

  1. SonarQube Server running (local installation, Docker, or cloud-hosted)

  2. SonarQube Token (generate in SonarQube under User > My Account > Security)

  3. Maven installed (3.x or higher)

  4. Java JDK installed (8 or higher)

Using Maven with SonarQube Plugin

Step 1: Add SonarQube Plugin to pom.xml

Add the following to your pom.xml:

<properties>
<sonar.host.url>http://localhost:9000</sonar.host.url>
<sonar.login>YOUR_SONARQUBE_TOKEN</sonar.login>
</properties>
<build>
    <plugins>
        <plugin>
             <groupId>org.sonarsource.scanner.maven</groupId>
             <artifactId>sonar-maven-plugin</artifactId>
             <version>3.9.1.2184</version>
        </plugin>
    </plugins>
</build>

<properties>
<!-- SonarQube Properties -->
<!-- SonarQube server URL -->
<sonar.host.url>http://localhost:9000</sonar.host.url> 
<!-- Your SonarQube token -->
<sonar.login>your-generated-token</sonar.login> 
<!-- Unique project key -->
<sonar.projectKey>your-project-key</sonar.projectKey> 
<!-- Project display name -->
<sonar.projectName>Your Project Name</sonar.projectName> 
<!-- Optional: Project version -->
<sonar.projectVersion>1.0</sonar.projectVersion> 
<!-- Optional: Source encoding -->
<sonar.sourceEncoding>UTF-8</sonar.sourceEncoding> 
</properties>

Step 2: Run Analysis

Run the following command in the project root:

mvn clean verify sonar:sonar

Using SonarScanner CLI (Multi-Language Project)

  1. Install SonarScanner CLI:

# For Linux/macOS

brew install sonar-scanner

# For Windows

choco install sonar-scanner

We can also download manually → SonarScanner CLI

Create sonar-project.properties:

sonar.projectKey=PROJECT_KEY
sonar.projectName=PROJECT_NAME
sonar.host.url=http://localhost:9000
sonar.login=YOUR_SONARQUBE_TOKEN
sonar.sources=src
sonar.exclusions=**/test/**, /target/

Run Analysis:

sonar-scanner

Use SonarScanner CLI only if:

  • You have a multi-language project

  • Your build process doesn’t use Maven

  • You want more control over the scan process

Jenkins Integration

  1. Install SonarQube Scanner Plugin in Jenkins

  2. Configure SonarQube Server in Jenkins (Manage Jenkins > Configure System)

  3. Add SonarQube Analysis Step in your pipeline:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('SonarQube Analysis') {
            steps {
                withSonarQubeEnv('SonarQube_Server') {
                    sh 'mvn sonar:sonar'
                }
            }
        }
    }
}

GitHub Actions

  1. Create a Workflow File (.github/workflows/sonar.yml):

       name: SonarQube Analysis
   on: [push]
   jobs:
   sonarqube:
   runs-on: ubuntu-latest
   steps:
   - uses: actions/checkout@v3
   - name: Set up JDK
   uses: actions/setup-java@v3
   with:
   java-version: '17'
   distribution: 'temurin'
   - name: Run SonarQube Analysis
   run: |
   mvn clean verify sonar:sonar \
   -Dsonar.host.url=${{ secrets.SONAR_HOST }} \
   -Dsonar.login=${{ secrets.SONAR_TOKEN }}
    • Add Secrets SONAR_TOKEN and SONAR_HOST in GitHub repository settings.

Key Notes to Remember

  1. Exclude Test Files:
    Use sonar.exclusions=**/test/** to exclude test files.

  2. Coverage Reports:
    Use tools like JaCoCo for code coverage:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.8</version>
    <executions>
        <execution>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>

        <execution>
            <id>report</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Multi-Module Projects:

Use sonar.modules in sonar-project.properties for multi-module projects.

Maven projects

  • No need for sonar-project.properties

  • SonarQube picks up configurations directly from the POM file (pom.xml)

Why no sonar-project.properties?

Maven uses the SonarQube plugin to read project metadata (name, version, sources, tests) directly from pom.xml.

Multi-module SonarQube analysis in Maven.

  • Before SonarQube 6.6: We could use sonar.modules in sonar-project.properties to handle multi-module projects.

  • After SonarQube 6.6: The sonar.modules property was deprecated — now, Maven's pom.xml handles multi-module projects natively.

Modern Approach: Multi-module Analysis Using Maven's POM (Post SonarQube 6.6)

If using Maven 3+ and SonarQube 6.6+ → Use Maven's native multi-module support (via pom.xml).

In a Maven multi-module project, the parent pom.xml defines submodules. SonarQube reads this directly.

Project structure:

/maven-project-root

│-- /module1

│ └── pom.xml

│-- /module2

│ └── pom.xml

└── pom.xml (parent POM)

Parent pom.xml:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-maven-project</artifactId>
    <version>1.0-SNAPSHOT>
    <packaging>pom</packaging>
    <modules>
        <module>module1</module>
        <module>module2</module>
    </modules>
    <build>
        <plugins>
            <plugin>
                <groupId>org.sonarsource.scanner.maven</groupId>
                <artifactId>sonar-maven-plugin</artifactId>
                <version>3.10.0.2594</version>
            </plugin>
        </plugins>
    </build>
</project>

Running SonarQube Analysis:

Run this in the root directory:

mvn clean verify sonar:sonar \
  -Dsonar.projectKey=my-maven-project \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=your_sonar_token

SonarQube will automatically detect all submodules and show them in the UI.

Deprecated Approach: Using sonar-project.properties (Pre SonarQube 6.6)

If you have a non-Maven project or need manual control → Use sonar-project.properties (remember it’s deprecated).

If you still want to understand the older method for learning purposes, here’s how it worked:

In the root directory, create sonar-project.properties:

# Main project settings

sonar.projectKey=my-maven-project
sonar.projectName=My Maven Multi-Module Project
sonar.projectVersion=1.0

# Modules

sonar.modules=module1,module2

# Module 1

module1.sonar.projectName=Module 1
module1.sonar.sources=module1/src/main/java
module1.sonar.tests=module1/src/test/java

# Module 2
module2.sonar.projectName=Module 2
module2.sonar.sources=module2/src/main/java
module2.sonar.tests=module2/src/test/java

# SonarQube server
sonar.host.url=http://localhost:9000
sonar.token=your_sonar_token

Running the scanner: sonar-scanner

This would push results for module1 and module2 as sub projects under the main project.

SonarQube Integration with dotNet

Prerequisites

  • SonarQube Server running (local installation, Docker, or cloud-hosted)
  • SonarQube Token (generate in SonarQube under User > My Account > Security)
  • .NET SDK installed (verify with dotnet --version)
  • SonarScanner for .NET installed (install globally using dotnet tool install --global dotnet-sonarscanner)
  • Java JDK installed (8 or higher, required for SonarQube)
  • SonarQube Project Key (create a project in SonarQube to obtain the key)
  • Build tool compatibility:
    • For .NET Core/.NET 5+: Use dotnet build
    • For .NET Framework: Use MSBuild.exe and SonarScanner.MSBuild.exe

Let me know if you need a step-by-step guide for a specific CI/CD pipeline like Jenkins, Azure DevOps, or GitHub Actions! 🚀

Step 1: Install the SonarScanner .NET Tool

dotnet tool install --global dotnet-sonarscanner

Step 2: Run Analysis

Start the Scanner (replace placeholders):

dotnet sonarscanner begin \
/k:"PROJECT_KEY" \
/d:sonar.host.url="http://localhost:9000" \
/d:sonar.login="YOUR_SONARQUBE_TOKEN" \
/d:sonar.cs.vscoveragexml.reportsPaths="**/*.coveragexml" \
/d:sonar.exclusions="**/bin/**/*, /obj//*, /TestResults//*"

Build the Project:

dotnet build

End the Scanner:

dotnet sonarscanner end /d:sonar.login="YOUR_SONARQUBE_TOKEN"

Example:

dotnet sonarscanner begin /k:"dotnet-two" /n:"dotnet-two" /v:"1.0" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="squ_794c4612899f738bc0ee615549e850a8605dd67a" /d:sonar.sources="." /d:sonar.exclusions="**/bin/**/*, /obj//*, /TestResults//*" /d:sonar.cs.opencover.reportsPaths="**/coverage.opencover.xml"

dotnet build

dotnet test --collect:"XPlat Code Coverage"

dotnet sonarscanner end /d:sonar.login="squ_794c4612899f738bc0ee615549e850a8605dd67a"

Notes

There is No sonar-project.properties in .NET projects.

Why there is no sonar-project.properties?
.NET uses MSBuild or dotnet CLI tools, and SonarQube is integrated via the SonarScanner for .NET which uses its own configuration style.

Using the SonarQube.Analysis.xml

We can also configure SonarQube using the SonarQube.Analysis.xml file or pass properties via the CLI.**
Cons in CLI:** It requires specifying the token in every command (not secure if stored in scripts).

Create SonarQube.Analysis.xml file:

<?xml version="1.0"?>
<SonarQubeAnalysisProperties xmlns="http://schemas.sonarsource.org/2016/05/SonarQubeAnalysisProperties.xsd">
    <Property Name="sonar.projectKey">my-dotnet-project</Property>
    <Property Name="sonar.host.url">http://localhost:9000</Property>
    <Property Name="sonar.token">your_sonar_token</Property>
</SonarQubeAnalysisProperties>

Run the commands (without passing parameters manually):

dotnet sonarscanner begin
dotnet build
dotnet sonarscanner end

Pros: Cleaner and more maintainable, More secure as it hides the token from command history, Useful for shared configurations across multiple projects.

Cons: Requires an additional configuration file.

Azure DevOps Integration

  1. Install the SonarQube Extension from the Azure Marketplace.

  2. Add Tasks to Pipeline (YAML example):

- task: SonarQubePrepare@5

inputs:
SonarQube: "SonarQube_Connection_Name"
scannerMode: "MSBuild"
projectKey: "PROJECT_KEY"
projectName: "PROJECT_NAME"

- task: DotNetCoreCLI@2
inputs:
command: "build"

- task: SonarQubeAnalyze@5
- task: SonarQubePublish@5

inputs:
pollingTimeoutSec: "300"

GitHub Actions

  1. Create a Workflow File (.github/workflows/sonar.yml):
name: SonarQube Analysis
on: [push]
jobs:
sonarqube:
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Setup .NET

uses: actions/setup-dotnet@v3
with:

dotnet-version: 6.0.x
- name: Install SonarScanner

run: dotnet tool install --global dotnet-sonarscanner
- name: Run SonarQube Analysis

run: |

dotnet sonarscanner begin /k:"PROJECT_KEY" /d:sonar.login="${{ secrets.SONAR_TOKEN }}" /d:sonar.host.url="${{ secrets.SONAR_HOST }}"

dotnet build

dotnet sonarscanner end /d:sonar.login="${{ secrets.SONAR_TOKEN }}”

Add Secrets SONAR_TOKEN and SONAR_HOST in GitHub repository settings.

SonarScanner CLI (Legacy)

Install SonarScanner CLI:

# For Linux/macOS

brew install sonar-scanner

# For Windows

choco install sonar-scanner

Create sonar-project.properties:

sonar.projectKey=PROJECT_KEY
sonar.projectName=PROJECT_NAME
sonar.host.url=http://localhost:9000
sonar.login=YOUR_SONARQUBE_TOKEN
sonar.sources=.
sonar.exclusions=**/bin/**, /obj/, /TestResults/
Run Analysis: sonar-scanner

Key Notes

  1. Exclude Test Projects: Use /d:sonar.exclusions="**/*Tests.cs" to ignore test files.

  2. Coverage Reports: Integrate with coverlet or OpenCover for coverage data.

  3. .NET Framework: Replace dotnet build with MSBuild.exe for .NET Framework projects.

  4. Security: Store SonarQube tokens as secrets (never hardcoded).

Troubleshooting

  1. Build Failures: Ensure dotnet build succeeds before analysis.

  2. Authentication Issues: Validate the SonarQube token and server URL.

  3. Logs: Check logs in .sonar or SonarQube.Analysis.xml.

SonarQube Integration with Angular

Prerequisites

  1. SonarQube Server running.

  2. SonarQube Token (generate in SonarQube under User > My Account > Security).

  3. Node.js and npm installed.

  4. Angular CLI installed (npm install -g @angular/cli).

Using SonarScanner CLI(Recommended)

Step 1: Install SonarScanner

npm install -g sonar-scanner

Step 2: Create sonar-project.properties

sonar.projectKey=PROJECT_KEY
sonar.projectName=PROJECT_NAME
sonar.projectVersion=1.0
sonar.host.url=http://localhost:9000
sonar.login=YOUR_SONARQUBE_TOKEN
sonar.sources=src
sonar.exclusions=**/node_modules/**, /dist/, /e2e/
sonar.tests=src
sonar.test.inclusions=**/*.spec.ts
sonar.language=ts
sonar.typescript.lcov.reportPaths=coverage/lcov.info
sonar.javascript.lcov.reportPaths=coverage/lcov.info

Step 3: Generate Coverage Report

Run tests with coverage:

ng test --code-coverage

Step 4: Run Analysis sonar-scanner

Note: Angular (JavaScript/TypeScript) projects

  • We can use sonar-project.properties.

  • Since Angular doesn’t have a "native" SonarQube plugin like Maven or .NET, SonarScanner CLI relies on this file.

Using Angular CLI Builder(Simple and Easy)

Install SonarQube Scanner:

npm install sonar-scanner --save-dev

Add Script to package.json:

"scripts": {
    "sonar": "sonar-scanner"
}

Run Analysis:

npm run sonar

GitHub Actions

Create a Workflow File (.github/workflows/sonar.yml):

name: SonarQube Analysis
on: [push]
jobs:
sonarqube:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js

uses: actions/setup-node@v3

with:

node-version: '16'
- name: Install dependencies

run: npm install
- name: Run tests with coverage

run: npm test -- --code-coverage
- name: Run SonarQube Analysis

run: |
npm install -g sonar-scanner

sonar-scanner \
-Dsonar.host.url=${{ secrets.SONAR_HOST }} \
-Dsonar.login=${{ secrets.SONAR_TOKEN }}

Add Secrets SONAR_TOKEN and SONAR_HOST in GitHub repository settings.

Jenkins Integration

  1. Install SonarQube Scanner Plugin in Jenkins.

  2. Configure SonarQube Server in Jenkins (Manage Jenkins > Configure System).

  3. Add SonarQube Analysis Step in your pipeline:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build -- --prod'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test -- --code-coverage'
            }
        }
        stage('SonarQube Analysis') {
            steps {
                withSonarQubeEnv('SonarQube_Server') {
                    sh 'sonar-scanner'
                }
            }
        }
    }
}

Key Notes

  1. Exclude Files: Use sonar.exclusions to exclude node_modules, dist, and e2e.

  2. Coverage Reports: Use ng test --code-coverage to generate lcov.info.

  3. Linting: Integrate with TSLint or ESLint for static code analysis.

Troubleshooting

  1. No Coverage Data: Ensure ng test --code-coverage is executed before analysis.

  2. Authentication Issues: Validate the SonarQube token and server URL.

  3. Logs: Check logs in .sonar or SonarQube.Analysis.xml.

Why to run tests for SonarQube in Maven, .NET, and Angular projects?

Running test cases is important because SonarQube uses test reports and coverage data to:

  • Measure code coverage: the percentage of code tested by unit tests.

  • Identify untested code paths: showing gaps in test coverage.

  • Ensure test quality: catching flaky tests or missing assertions.

However, SonarQube doesn’t run the tests itself — it relies on you to run the tests and generate reports. These reports are then uploaded to SonarQube for analysis.

Why exclude test folders/files (like /test/ or /target/)?

We exclude test files because:

  1. Test files aren't part of the production code: They don’t contribute to the final build (like classes or components).

  2. SonarQube focuses on the quality of the main codebase: It checks if the main (production) code is properly tested, not the tests themselves.

  3. To avoid skewing metrics: Including test files could inflate metrics like "lines of code" and give false coverage percentages.

What happens if you don’t exclude test folders?

  • False positives: SonarQube might flag test mocks or helper functions as code smells or bugs, even though they are not production code.

  • Misleading coverage — It could show 100% coverage if your tests are included, giving a false sense of security.

What if we skip running tests altogether?

  • Without tests:

    • SonarQube will show 0% test coverage.

    • It may lower the quality gate score (if a minimum test coverage is required).

    • You lose critical insights about untested code paths.

  • With tests:

    • SonarQube calculates coverage and highlights untested areas.

    • It improves your code quality score by proving your code is well-tested.

    • You can enforce rules like "Code must have at least 80% coverage."

What is Production Code Analysis?

Production code analysis means scanning only the main source code (the code that goes into the final build or deployment) not tests, mocks, or temporary files — to check for:

  • Bugs — Errors that could cause runtime issues.

  • Code smells — Maintainability issues (like duplicated code, unused variables).

  • Vulnerabilities — Security flaws (like SQL injection or hard-coded passwords).

  • Technical debt — Estimation of effort needed to fix quality issues.

SonarQube focuses on production code because:

  • That’s the code your users interact with.

  • It ensures your app runs securely and efficiently.

  • Testing code (mocks, unit tests, etc.) isn’t part of what goes live.

How to perform Production Code Analysis:

Maven:

Ensure test files are excluded by defining the sonar.sources property:

# sonar-project.properties or in pom.xml
sonar.sources=src/main/java
sonar.exclusions=**/test/**, /target/

Then, run SonarQube without considering tests:

mvn clean verify sonar:sonar

.NET:

Exclude test projects or test folders in sonar-project.properties:

sonar.exclusions=**/Tests/*.cs, /test//*.cs

Angular:

Exclude test files in sonar-project.properties:

sonar.sources=src/app
sonar.exclusions=**/*.spec.ts, /test/, /dist/

Analyze:

sonar-scanner

Why is Production Code Analysis important?

  1. Security — Finds security vulnerabilities in live code.

  2. Performance — Highlights inefficient code.

  3. Maintainability — Ensures clean, readable, and maintainable code.

  4. Compliance — Helps you meet coding standards (like OWASP, CWE).

Thank You! That’s all by my side.

0
Subscribe to my newsletter

Read articles from Murtuza Rangwala directly inside your inbox. Subscribe to the newsletter, and don't miss out.

sonar-scannersonarqubesonarqube installationDevopsDevops articlesdeploymentTesting.NETAngularmaven

Written by

Murtuza Rangwala
Murtuza Rangwala

Learner.