Hi everyone. I've been lurking for a while, learning a lot from you all. 😊
We're still on SonarQube 8.9 LTS and need branch analysis for our workflow. I found the community "branch plugin" for pre-9.2 versions, but I'm nervous about stability. Has anyone here actually run it in production? Any major pitfalls or issues you ran into?
I'm mainly worried about it breaking our existing setup or causing false positives/negatives in analysis. Any advice would be really helpful.
It's a ticking time bomb. I've seen two teams in my orbit try that community branch plugin on 8.9, and both rolled it back within a month.
Stability was the least of their worries. The real issue was analysis drift. The plugin's method for storing branch data started corrupting the main project's historical metrics after a few scan cycles. You'd get false regressions on your main branch because the baseline numbers got scrambled.
My advice? Don't treat it as a production solution. If you absolutely must have branch analysis on 8.9, use it as a temporary bridge while you plan your upgrade to a supported version. Otherwise you're just trading one workflow headache for a data integrity disaster.
Question everything.
You've got good instincts to be nervous. I'll be the one to push back slightly on the "ticking time bomb" characterization, because it implies you have a choice. You don't.
The community plugin is, to be brutally honest, a hack. It's reverse-engineered plumbing for a feature the vendor explicitly removed and walled off. So of course it corrupts historical metrics - it's poking at database tables that were never meant to be accessed that way in 8.9.
But calling it a "temporary bridge" is a bit of a fantasy. If your workflow is locked into needing branch analysis, your real choice is between running this unstable plugin or embarking on a massive, potentially breaking upgrade to 9.2+ during an LTS cycle. Which one is more "production" for your team? The devil you know, with corrupted baselines you can maybe monitor for, or the multi-month migration project with its own set of unknown pitfalls?
The plugin won't give you false positives in the analysis itself. It'll just slowly make the numbers on your main branch dashboard meaningless. Whether that's an acceptable trade-off depends entirely on how much you actually trust those historical metrics for decision-making. Most teams just glance at the latest leak period anyway.
Just my 2 cents
Yeah, that "analysis drift" is such a sneaky problem. A friend's team didn't notice the corruption right away, so they spent a week chasing phantom regressions before they figured out the baseline was shifting. It really undermines trust in the whole dashboard.
The "temporary bridge" idea is sound in theory, but you have to be militant about it. I'd only consider the plugin if you have a hard deadline for the 9.2+ upgrade already locked in, like within the next sprint. Otherwise, it's too easy for that "temporary" state to become permanent tech debt.
Cheers, Matt
Yeah, that's exactly the kind of scenario that keeps me up at night. You spend more time debugging your tools than your actual code.
> militant about it
That's the key, I think, but it's so hard in practice. Has anyone actually pulled off this temporary bridge successfully? I'm picturing setting a hard calendar reminder and maybe even a pre-upgrade task force, but I'm curious if there's a concrete step-by-step plan that worked. Like, did you freeze feature development on the plugin while planning the upgrade?
One step at a time