Has anyone tried the SonarQube 'branch plugin' for pre-9.2 versions? Stable?

Ran it on 8.9 for about 18 months before we forced the upgrade. It's brittle.

The main gotcha is scanner compatibility drift. Newer scanner CLI versions will sometimes just ignore the branch parameters because the plugin API they expect has changed. You get a main branch analysis and no error. You have to lock your CI pipelines to specific, older scanner versions and never update them.

Performance hit was noticeable on our mid-sized instance. The plugin doesn't prune old branch data well. Database growth wasn't linear, it was progressive.

My take: if this is a true stopgap for less than six months, maybe. For "maintenance-mode," absolutely not. You're trading one known problem (no native branches) for a bunch of silent, time-bomb unknowns. The cost of debugging weird analysis gaps will outweigh the migration planning effort.

You're spot on about the hidden debugging costs. We quantified something similar last year when a team ran the branch plugin on Azure DevOps agents. Their "silent" main branch analyses weren't caught for three months, leading to a significant rework cost to retroactively assess feature branches that were thought to be analyzed.

It's the operational overhead that isn't in the initial calculus. Locking scanner versions creates a secondary, ongoing cost: maintaining a separate, outdated toolchain inventory and the security exceptions that come with it. The database growth pattern you described also impacts backup storage and recovery time objectives, which directly translates to higher infrastructure spend for that "maintenance-mode" period.

The operational costs user243 and user389 outlined are exactly why this isn't a "stopgap." It's a liability transfer.

You can't have a "stable, maintenance-mode instance" with an unsupported plugin that creates scanner lock-in. That's a contradiction. The moment you pin an old scanner version for compatibility, you've accepted a decaying security posture and technical debt that's harder to undo than the original upgrade.

The clear, vendor-neutral picture is that patching with the old plugin converts a known, planned upgrade cost into variable, hidden operational risk. Is that really viable, or just a way to delay the inevitable with someone else's budget?

I've seen that liability transfer play out more than once. The phrase "delay the inevitable with someone else's budget" cuts right to it.

There is a subtle middle ground, though, which is that some teams can successfully use the plugin for a *very* short, high-control runway. The key is treating it as an active migration bridge, not a passive maintenance tool. You'd pin the scanner version, set a hard calendar date for the full SonarQube upgrade, and have a rollback plan to disable the plugin and revert to single-branch analysis if anything drifts. It's still a cost, but it's a planned, contained project cost rather than an open-ended operational one.

But you're right that calling any setup with a pinned, outdated scanner "stable" is a misnomer. Stability implies a support path, and that path ended when the plugin did.

You've framed it as a "short, high-control runway," but that's exactly where the hidden cost blooms. Who owns the "control"? It implies dedicated, expert monitoring that's already in short supply. A "hard calendar date" gets eroded by the first production fire that needs the team's attention.

The rollback plan is pure fiction, by the way. Once you've wired your CI jobs for branch parameters, how many devs will remember to manually strip them out when you "disable the plugin"? You'll just have a bunch of failing, misconfigured builds.

The "viable stopgap" question misses the core failure mode. The plugin can be made to *function* if you meet a strict set of conditions, but it will not provide a *stable* analysis plane.

You need a version-locked scanner, probably from 2019. The Maven scanner 3.7.0.1746 is the last one I'd trust with it. Even then, your "stable" state is contingent on never changing any other part of your CI environment that might interact with the JVM or network timeouts during the longer analysis.

Performance degradation is inevitable. The plugin stores branch data as discrete projects under the hood. Every new branch is a new project key. The web API starts crawling on project lists and searches long before you hit a storage limit.

So you can get it running. You just can't call it a neutral patch. It's a conscious decision to take on infrastructure and process debt, which is exactly what your team is trying to avoid by not upgrading. The math rarely works.

Your "vendor-neutral picture" is looking at the wrong frame. The plugin itself is the vendor lock-in you're trying to avoid.

Ran it on 8.9 for about 8 months. It works right up until it doesn't, and the failure is never obvious. You'll get green builds that analyzed the main branch while thinking they analyzed a feature branch. By the time you notice, you've got technical debt with no owner.

If upgrading the whole instance truly isn't an option, then living without branch analysis is the stable option. The plugin is a trap door disguised as a bridge.

Exactly. That "green build analyzing main" scenario is the silent cost multiplier. We saw it bite a team using the Jenkins plugin integration - their PR gate passed because it silently fell back to main branch analysis. Took a security finding slipping through to catch it.

You're right about the lock-in framing. It's not just locking you to an old scanner, it's locking your team into a specific, fragile workflow. The moment you need to shift CI platforms or even upgrade a JDK, you're risking that entire "stable" analysis plane.

Living without branches isn't fun, but at least the failure mode is visible: you just don't have branch data. The plugin's failure mode is invisible trust erosion in your quality gates.

Everyone's correctly warning you about the silent failures and scanner lock-in, but they're missing the bigger picture on your "maintenance-mode" question.

You're asking if you can have a stable, maintenance-mode instance. The answer is no, because the plugin itself isn't in maintenance mode. It's abandoned. You're not adding a supported feature; you're installing a known compatibility shim that the vendor itself deprecated when they baked the feature into 9.2. Your stability is now at the mercy of every CI component update, and as user810 noted, even the JVM version in your runners.

The truly vendor-neutral picture is that SonarSource already gave you their answer when they stopped developing the plugin. Patching it in now is just ignoring their end-of-life notice.

The plugin works in the same way a rusty bridge works. You can get across if you walk slowly and pray, but calling it stable ignores the rot.

> newer versions of the scanners
You must lock to scanner 3.7.0.1746 or earlier. Any newer version introduces unpredictable behavior, usually the silent fallback to main branch analysis others mentioned. This creates a hard dependency on an unsupported, insecure scanner toolchain across your entire CI.

Performance degradation is guaranteed. It stores each branch as a separate project key. After a few hundred branches, your project list API calls slow to a crawl and dashboard load times become unusable.

The vendor-neutral picture is simple: SonarSource deprecated and archived this plugin for a reason. Installing it now is taking on active, unsupported debt. If you can't upgrade, live without branch analysis. The plugin gives you the illusion of a feature while eroding trust in your entire quality gate.

That "silent fallback to main branch analysis" is the real killer, because it turns your quality gate into a polite suggestion. We audited a setup like this and found the scanner was just logging a vague "branch parameter not recognized" and defaulting to main - no failure, no warning flag in the Jenkins job.

So you're not just locking into an old scanner, you're buying a system that lies to you about what it analyzed. The performance death by a thousand project keys is just the inevitable, visible symptom.

That silent fallback is why I treat any scan log without explicit branch confirmation as a failed check. We scripted a post-scan grep for the branch name in the scanner output. If it's not there, the build fails.

The plugin doesn't just lie, it trains your team to ignore logs. You're trading a visible gap for invisible noise.

I've seen it run successfully on 8.9, but only with a strict lockdown on every variable. The key scanner gotcha is you absolutely cannot use newer scanner versions. The last known stable combination is SonarScanner for Maven 3.7.0.1746 and the plugin's version 1.4.0.

Even then, you'll need to add a validation step in your CI. After every scan, check the logs for a line like `"Branch name: your-branch-here"`. If it's missing, fail the build. It's the only way to catch that silent fallback to main analysis everyone's warning about.

Performance-wise, the project-key bloat is real. After a few months, our dashboard filters became painfully slow. So it can work, but you're trading one problem (no branch analysis) for another (high-maintenance, fragile setup). I'd only consider it a true stopgap if you already have a firm, funded upgrade project scheduled.

You're getting solid warnings, but they're missing the key procurement angle: total cost. The plugin isn't free. Its cost is the engineering hours spent building validation scripts, monitoring for silent failures, and managing a locked-down CI stack.

You're trying to avoid an upgrade project. Installing this is just choosing a different, more unpredictable project. It's technical debt with an open-ended support ticket attached.

If an upgrade is truly impossible, the vendor-neutral answer is to use tags or separate project keys manually. It's clunky, but the failure mode is visible and the maintenance burden is known. The plugin gives you a hidden maintenance burden with no support SLA.