I look after CI for a ~1.7M LOC monorepo,mainly java. Writing as an individual engineer, not for my employer. (individual eng. that is a little bit more and more frustrated working with sonar)
I want to raise three things: sensors we can’t disable, a performance bug that makes one of them 4× worse than it needs to be on PR scans, and the fact that none of this behavior changes was announced. (blog posts or notifications doesn’t really count, particularly when they are made the day of a change.)
Where the time goes
12 PR analyses and 12 main-branch analyses, week of Sep 14–18. sonar-maven-plugin 5.7.0.6970, core extensions architecture, a3s, sca, -Xmx10192m, all on identical runners.
| PR analysis | Main-branch analysis | |
|---|---|---|
Mean Analysis total time |
16 min 52 s | 35 min 28 s |
| Median | 15 min 35 s | 35 min 17 s |
| Range | 13:22 – 21:57 | 34:17 – 37:21 |
Top sensors on PRs:
| Sensor | Mean | Share |
|---|---|---|
JavaSecuritySensor [security] |
4 min 17 s | 25 % |
CveReachabilitySensor [cvereachability] |
3 min 34 s | 21 % |
javabugs [dbd] |
1 min 51 s | 11 % |
JaCoCo XML Report Importer |
1 min 01 s | 6 % |
| other 68 sensors | 3 min 04 s | 18 % |
| non-sensor (SCA dependency load, publish, gate) | 2 min 29 s | 15 % |
Three project-global sensors are 57 % of every PR analysis. Being global, they run as a single pass over the whole reactor — module parallelism does nothing for them.
For context: before we moved to SonarQube Cloud with Advanced Security, branch analyses took roughly 10–15 minutes. That’s from memory, since our pre-migration CI logs have rotated out. Main is now 35 minutes. JavaSecuritySensor didn’t exist in our pipeline then either; we accepted it when it arrived, on the reasoning that better security detection is worth paying for. That trade was explicitly accepted. What followed wasn’t.
What it costs us
At our merge rate — 483 successful PR analyses and 25 main-branch analyses in that one week:
- 150 hours per week of Sonar analysis wall-clock.
- 29 hours per week is
CveReachabilitySensoralone — roughly 1,500 hours a year for a sensor we didn’t choose and can’t switch off. - Developers wait ~17 minutes for a PR gate. That’s well past the point where people stop waiting and go do something else, and the context-switch is the actual cost — not the runner bill.
- Main takes 35 minutes, so anything that lands broken on main surfaces half an hour later.
1. sonar.sca.enabled is all-or-nothing, and that’s forcing a bad decision
We adopted your SCA deliberately, to depend less on another “painful to work with” vendor for day-to-day dependency work. SCA itself does its job. But reachability analysis was added underneath it, is now our second-largest cost on PR, and your documentation confirms there’s no way to separate them: the parameter set is sonar.sca.enabled, sonar.sca.exclusions, sonar.sca.allowManifestFailures, sonar.sca.mavenOptions, the per-ecosystem *NoResolve flags and sonar.sca.sbomImportPaths. No reachability toggle.
On main, reachability costs 52 s, but on PRs it costs 3 min 34 s, which is not acceptable and the only lever available is to disable SCA entirely. So that’s what we may do if that’s not addressed.
The practical result is that a bundled sensor may push clients turning off a security feature they may actively used. I don’t think that’s the outcome you’re aiming for, and I don’t think it’s a reasonable position to put a paying customer in.
Ask: let us disable individual sensors — and let us do it once, at project level in the UI. A scanner property alone doesn’t solve this. We maintain many long-lived release branches; a -D flag means editing CI config on every one of them, and doing it again for each new branch, just to get back the behaviour we had before. A project-level setting, applying to all branches and PRs, is what actually restores control. sonar.sca.reachability.enabled would fix today’s problem; a general sonar.sensors.exclude would fix this whole category permanently.
2. Reachability is 4× slower on PRs than on main, doing identical work
This looks like a bug rather than a design cost, and fixing it would remove most of my objection.
Same project, same commit range, same runner type. The sensor’s own trace reports 103 170 UCFGs on main and 103 171 on the PR — same graph, ~996 k nodes through Tarjan SCC on both sides:
| Phase | Main | PR | Ratio |
|---|---|---|---|
Load UCFGs |
10.07 s | 1 min 18.05 s | ×7.8 |
Create runtime call graph |
29.55 s | 1 min 44.00 s | ×3.5 |
| — VTA #1 propagation graph | 12.48 s | 57.60 s | ×4.6 |
| — VTA #2 propagation graph | 10.08 s | 32.46 s | ×3.2 |
| — Tarjan SCC (~996 k nodes) | 1.34 s | 2.87 s | ×2.1 |
Find reachable paths |
7.96 s | 31.77 s | ×4.0 |
| Total java process | 50.08 s | 3 min 37.06 s | ×4.3 |
Across 12 runs each:
| Main (n=12) | PR (n=12) | |
|---|---|---|
| Mean | 53.3 s | 3 min 34 s |
| Range | 50.1 – 56.7 s | 1:46 – 4:42 |
| Coefficient of variation | 5 % | 20 % |
Main is metronomic; PR mode is 4× slower and four times noisier on the same hardware. The slowdown is uniform across phases that stress different resources — I/O during UCFG load, CPU and allocation during graph construction, traversal during path search — so it doesn’t look algorithmic. Something about PR-mode execution is throttling the whole JVM.
A related clue: JavaSensor shows the same signature (1 % variation on main, 61 % on PRs), and in our noisiest PR run the two move in opposite directions — the sample’s fastest reachability (1:46) came alongside its slowest Java analysis (2:28). That pattern suggests contention inside the scanner JVM between cache-restore and analysis work.
Happy to provide run IDs, full scanner logs, or a GC/JFR capture privately.
3. None of this was announced
New sensors appeared in our pipeline and changed both our build time and our memory ceiling. We weren’t told. We found out by reading scanner logs after CI slowed down — and after raising the scanner heap for the second time in four months.
Release notes, forum threads and roadmap boards don’t cover this. A SaaS customer shouldn’t have to monitor a vendor’s changelog to keep their pipeline working. If a change adds minutes to every analysis or raises the scanner’s memory requirement, that needs to reach the person who owns the pipeline — an in-product admin notification, an email to org admins. Ideally with a window during which the new analyzer is opt-in.
As it stands, analysis quietly gets slower and hungrier, and we discover it when something breaks. For a paid SaaS product, that isn’t acceptable.
What I’m asking for
- Per-sensor opt-out, configurable at project level so it applies across all branches and PRs without touching CI config on each one. At minimum, decouple reachability from
sonar.sca.enabled. - Investigate the 4× PR-vs-main gap on
CveReachabilitySensor, and the same signature onJavaSecuritySensor. Identical workload, 4× the time, same hardware. - Tell customers in-product before shipping changes that add measurable time or memory, and make new analyzers opt-in during a transition period.
Sonar detection quality is good, and the UX is ahead of some main alternative I’m aware of. But “strong detection, painful to work with” is how good tools lose users who otherwise defend them. Please give us more control over what runs and a heads-up when things change, and most of this goes away.