Branch Analysis in SonarQube: When to Enable All Branches vs. Selected Branches

Problem Statement

Your team uses SonarQube to enforce code quality, but you’re unsure whether to run Branch Analysis on every branch or only on a subset (e.g., pull‑request and feature branches). The choice impacts CI time, database size, and license compliance.

Decision Constraints

• License Level: Community edition supports only the default branch; Enterprise and Developer editions allow multiple branches.
• Repository Size: Large repos can cause long analysis times and high storage usage.
• CI Pipeline Complexity: Adding a branch analysis step may require changes to existing jobs.
• Quality Visibility: Teams want to see regressions on all branches, not just PRs.

Option Comparison

Option	Branches Analyzed	Resource Impact	License Requirement	Integration Effort
All Branches	Every branch in the repo	High: longer CI jobs, larger DB	Enterprise or Developer	Minimal: same scanner command, but run per branch
Selected Branches	PRs or specific feature branches	Moderate: only triggered branches run analysis	Developer or Enterprise (Enterprise allows granular limits)	Moderate: need to filter branches in CI and set properties
Default Only (Community)	Only default branch	Low	Community	None: default behavior

Trade‑Off Analysis

• Visibility vs. Cost: Analyzing all branches gives full visibility but can double CI time on a 50‑branch repo. Selecting only PRs keeps CI fast but may miss regressions on long‑lived feature branches.
• Database Growth: Each branch creates a separate view in SonarQube. With 100 branches, the DB can grow by several GB, potentially hitting storage limits on the server.
• Parallel Analysis: Enterprise edition allows up to 10 parallel analyses per project. If you run analyses for every branch concurrently, you might hit the limit and queue jobs, adding latency.
• CI Complexity: In a monorepo, the CI pipeline must detect the branch name and set the appropriate scanner property. A mis‑configured property can cause duplicate analyses or data loss.

Implementation Example

Below is a minimal SonarScanner invocation that enables branch analysis for a feature branch. Replace the placeholders with your values.

# Run from the CI job that checks out the branch
sonar-scanner \
  -Dsonar.projectKey=MY_PROJECT \
  -Dsonar.sources=. \
  -Dsonar.branch.name=${CI_BRANCH_NAME} \
  -Dsonar.host.url=https://sonarqube.example.com \
  -Dsonar.login=${SONAR_TOKEN}

For pull‑request analysis (e.g., GitHub Actions), use the PR‑specific properties:

sonar-scanner \
  -Dsonar.projectKey=MY_PROJECT \
  -Dsonar.sources=. \
  -Dsonar.pullrequest.key=${PR_NUMBER} \
  -Dsonar.pullrequest.branch=${PR_BRANCH} \
  -Dsonar.pullrequest.base=${BASE_BRANCH} \
  -Dsonar.host.url=https://sonarqube.example.com \
  -Dsonar.login=${SONAR_TOKEN}

Key points:

• Use sonar.branch.name for regular branch analysis. The value must match the exact branch name in the VCS.
• For PRs, the pullrequest properties are required; SonarQube automatically decorates the PR in the UI.
• Ensure the CI job runs the scanner only once per branch or PR to avoid duplicate analyses.

Monitoring & Validation

1. After enabling branch analysis, navigate to the project > Branches & Pull Requests in SonarQube. The new branch should appear with its own dashboard.
2. In the CI logs, look for the line "Analyzing branch: branch‑name" that SonarScanner outputs.
3. Check the database size: SELECT pg_size_pretty(pg_database_size('sonarqube')); on PostgreSQL or the equivalent for your DB. Compare before/after to quantify impact.
4. Measure CI job duration before and after the change. A 30% increase might be acceptable if the visibility benefit outweighs the cost.

Conclusion

If your team needs full visibility and you’re on Enterprise or Developer edition, enabling all branches is the safest choice. For smaller teams or when resource constraints are tight, restrict analysis to PRs or a limited set of feature branches. Whichever path you choose, keep an eye on CI times and database growth, and adjust the branch list in SonarQube’s project settings as your workflow evolves.