SonarQube Intermediate — New Code, Branch Analysis & Coverage Integration

The New Code Period, in depth

Common New Code definitions:
  - "Previous version" -- since the last release/tag
  - "Number of days" -- e.g. the last 30 days of changes
  - "Specified reference branch" -- diff against main/a baseline branch

Choosing the right New Code definition matters — "number of days" can be misleading for a project with irregular release cadence (a long-untouched branch suddenly getting a burst of changes might partially fall outside a fixed day-window in a confusing way), while "reference branch" comparison is often the clearest, most intuitive definition for feature-branch-based workflows, directly answering "what did THIS branch actually change relative to main."

Branch Analysis

bash

# Analyze a specific branch, not just the default
sonar-scanner \
  -Dsonar.branch.name=feature/my-feature \
  -Dsonar.projectKey=my-project

Branch analysis lets SonarQube track quality per branch, not just for the default/main branch — useful for long-lived feature branches where you want ongoing feedback before the branch is ready to merge, distinct from pull request analysis (which is specifically oriented around decorating a PR for review, tied to that PR's lifecycle).

Pull Request Decoration

bash

sonar-scanner \
  -Dsonar.pullrequest.key=42 \
  -Dsonar.pullrequest.branch=feature/my-branch \
  -Dsonar.pullrequest.base=main

PR analysis posts findings directly onto the pull request in the source control platform (GitHub, GitLab, Azure DevOps, Bitbucket) — inline comments on the specific changed lines, and an overall Quality Gate status check. This is what actually gets a reviewer's attention at the moment it matters (during PR review) rather than requiring someone to separately check a SonarQube dashboard after the fact.

Code Coverage Integration

SonarQube does NOT run tests or compute coverage itself -- it
IMPORTS coverage reports generated by the project's own test
tooling (JaCoCo for Java, coverage.py for Python, Istanbul/nyc
for JavaScript, etc.) and displays/gates on that imported data.

Wiring up a report path looks like this:

bash

# Example: importing a JaCoCo XML coverage report
sonar-scanner \
  -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

A common point of confusion worth clearing up directly: SonarQube's coverage metrics are only as good as the actual test run and report generation that happened BEFORE the scan — if tests weren't actually run (or the coverage report path is misconfigured), SonarQube will show 0% coverage, not because coverage is genuinely zero, but because it never received the report data at all.

Duplication Detection

SonarQube detects duplicated code blocks across the analyzed
codebase, tracked as a percentage of duplicated lines -- a real,
distinct maintainability signal: duplicated logic means a bug fix
or behavior change made in one copy is easy to forget to also
apply to the other copy(ies).

Duplication detection works on token-level similarity (not exact textual match alone), catching duplicated logic even with minor variable-naming differences between the copies — a meaningfully more useful signal than a naive exact-text-match approach would provide.

Technical Debt & the "Remediation Effort" Metric

SonarQube estimates a "remediation effort" (in time) for
maintainability-related Code Smells -- a rough, standardized
estimate of how long it would take to fix a given issue,
aggregated into an overall "technical debt" figure for the project

This isn't meant as a precise, literal time estimate for planning purposes — it's a standardized, comparable metric that lets a team track whether technical debt is trending up or down over time, and roughly compare the relative maintainability burden between different projects using a consistent measure, rather than an exact task-estimation tool.

Try It (2 Minutes)

Using the coverage integration section above:

1.A project's SonarQube dashboard shows 0% code coverage, but the team is confident they have meaningful test coverage locally. What's the most likely explanation?

2.What's the practical difference between "branch analysis" and "pull request analysis"?

3.Why does duplication detection use token-level similarity rather than requiring an exact textual match?

You should land on: SonarQube doesn't run tests itself — it imports a coverage report generated by the project's own test tooling; 0% almost always means the coverage report wasn't actually generated, or its path/format is misconfigured in the scanner invocation, not that tests genuinely don't exist; branch analysis tracks ongoing quality for a specific branch over its own lifecycle (useful for long-lived branches); PR analysis is specifically oriented around decorating one pull request for review, tied to that PR's lifecycle; token-level similarity catches genuinely duplicated LOGIC even with minor variable-naming differences between copies, which an exact-text-match approach would miss despite the underlying duplication risk being identical.

SonarQube — Intermediate