SonarQube Branch Analysis and Pull Requests
Modern teams use feature branches and pull requests to manage code changes. SonarQube can analyze each branch and pull request independently and show exactly which new issues were introduced by a specific set of changes. This topic explains how branch analysis works and how pull request analysis catches problems before code is merged.
Community Edition Limitation
Branch analysis and pull request decoration are available starting from the Developer Edition. The Community Edition only analyzes the main branch. If you use the Community Edition, you can still run scans on feature branches — but each scan overwrites the same project history rather than keeping separate branch data.
COMMUNITY EDITION DEVELOPER EDITION+ ------------------- --------------------------- One branch per project Unlimited branches No PR decoration Full PR decoration Free Paid subscription
How Branch Analysis Works
In the Developer Edition, every branch gets its own independent set of issues, metrics, and history inside the same project. The main branch is the reference branch. Feature branches are compared against it to identify new issues.
PROJECT: customer-portal
|
+-- Branch: main (reference branch)
| Bugs: 3 Smells: 24 Coverage: 71%
|
+-- Branch: feature/login (feature branch)
| NEW Bugs: 1 NEW Smells: 3 Coverage: 68%
| Quality Gate: FAILED (new bug introduced)
|
+-- Branch: hotfix/token-expiry
NEW Bugs: 0 NEW Smells: 0 Coverage: 73%
Quality Gate: PASSED
Configuring Branch Analysis in the Scanner
Pass the branch name to the scanner using the sonar.branch.name property:
# For a feature branch scan
sonar-scanner \
-Dsonar.projectKey=com.acme:customer-portal \
-Dsonar.branch.name=feature/login \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.token=sqp_your_token
# In a CI environment, read the branch name from the environment
sonar-scanner \
-Dsonar.projectKey=com.acme:customer-portal \
-Dsonar.branch.name=${GIT_BRANCH} \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.token=sqp_your_token
Viewing Branch Results in the Dashboard
A branch selector dropdown appears at the top of the project dashboard when multiple branches have been analyzed. Switch between branches to see each branch's independent metrics and issues.
PROJECT DASHBOARD +----------------------------------------------+ | Customer Portal [Branch: main ▼] | | [ main ] | | [ feature/login ] | | [ hotfix/token ] | +----------------------------------------------+ Select a branch to see its scan results.
Pull Request Analysis
A pull request scan analyzes only the code changes introduced in the PR — the diff between the feature branch and the target branch. SonarQube reports only new issues found in those changed lines.
PULL REQUEST ANALYSIS FLOW | +-- Developer opens PR: feature/login → main | +-- CI pipeline triggers PR scan | sonar.pullrequest.key=142 | sonar.pullrequest.branch=feature/login | sonar.pullrequest.base=main | +-- SonarQube analyzes only the changed files | +-- Issues found ONLY in new/changed lines | +-- Quality Gate checks new code conditions | +-- Result posted back to GitHub/GitLab/ADO
PR Scanner Configuration
sonar-scanner \ -Dsonar.projectKey=com.acme:customer-portal \ -Dsonar.pullrequest.key=142 \ -Dsonar.pullrequest.branch=feature/login \ -Dsonar.pullrequest.base=main \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.token=sqp_your_token
When using CI/CD integrations like Jenkins or GitHub Actions, these values are typically populated automatically from environment variables provided by the CI platform. You rarely need to set them manually.
Pull Request Decoration
Pull request decoration means SonarQube posts the analysis results directly on the PR page in your DevOps platform. Reviewers see the Quality Gate status and individual issue annotations without leaving the PR interface.
GITHUB PULL REQUEST WITH DECORATION +----------------------------------------------+ | PR #142: Add login feature | | base: main compare: feature/login | | | | Checks: | | [SonarQube Quality Gate: FAILED] ✗ | | | | Files changed: 4 | | | | LoginController.java | | Line 47: [!] SQL Injection vulnerability | | Line 89: [!] Null pointer dereference (bug) | | | | AuthService.java | | Line 22: [i] Method too long (code smell) | +----------------------------------------------+
Setting Up PR Decoration for GitHub
- Create a GitHub App with permissions: Pull requests: Read & Write
- Install the GitHub App in your repository or organization
- In SonarQube: Administration > Configuration > GitHub
- Enter the GitHub App ID, App slug, and private key
- SonarQube auto-detects the repository from the project configuration
Setting Up PR Decoration for GitLab
IN SONARQUBE: Administration > Configuration > GitLab GitLab URL: https://gitlab.com Personal Access Token: [token with api scope] IN PROJECT SETTINGS: Project Settings > General Settings > Pull Request Decoration GitLab Project ID: 12345678
Branch Purging
Long-running feature branches accumulate analysis data over time. SonarQube automatically deletes branch data for branches that have not been analyzed for a set number of days. The default is 30 days. Administrators can change this at Administration > Configuration > General > Number of days before deleting inactive short-living branches.
BRANCH LIFECYCLE Day 1: Branch created, first scan Day 15: Branch still active, scans running Day 30: Branch inactive (no new scans) Day 31: SonarQube deletes branch data automatically
The main branch and branches marked as long-lived are never auto-purged.
Long-Lived vs Short-Lived Branches
LONG-LIVED BRANCH SHORT-LIVED BRANCH (e.g., main, develop) (e.g., feature/*, hotfix/*) --------------------- ------------------------- Persistent history Temporary — deleted after merge Full quality tracking Focus on new issues only Quality Gate on all code Quality Gate on new code only Never auto-deleted Auto-deleted after inactivity
SonarQube automatically classifies branches based on patterns. Administrators can define patterns in Administration > Configuration > Branches and Pull Requests.