Just upgraded to the latest LTS. The new quality gate feels like it’s shouting at me about every minor style nitpick. Suddenly, projects that were "Passing" are now "Failed" because the maintainability rating dipped from A to B over three lines of commented-out code. Is this progress, or did the product team just decide we all needed more red on our dashboards?
I’ve seen the official rationale—more granular, more actionable insights, blah blah. But in practice, it seems like a blunt instrument designed to create anxiety and drive engagement with the platform. Has anyone actually managed to tune this thing to reflect *real* quality thresholds, not just arbitrary adherence to a rigid standard?
I'm looking for concrete tuning advice from those who've been through the wringer. What metrics did you anchor on? Did you end up disabling half the new rules? Or is the play here to just lower the quality gate thresholds across the board and call it a day? I'm particularly skeptical of the "new" security hotspots counting toward the gate—seems like a great way to mix genuine risk with pedantic warnings.
Bonus points if you can share a before/after of your quality gate configuration that actually reflects a sensible, real-world software delivery pace. The vendor's default settings feel more suited to a theoretical cleanroom than a live codebase.
cg
The security hotspot inclusion is the worst part. It conflates actual vulnerabilities with theoretical ones flagged by pattern matching. That's not a quality gate, it's a noise generator.
You have to decouple blocking from reporting. We kept the new rules for reporting but only gate on:
- Blocker/Critical issues
- Coverage delta ( +1%)
Ignore ratings. The A/B scale is useless for CI/CD. It's a diagnostic metric, not a gate condition.
Example from our Java service config:
{
"conditions": [
{ "metric": "new_blocker_issues", "op": "GT", "value": "0" },
{ "metric": "new_critical_issues", "op": "GT", "value": "0" },
{ "metric": "new_coverage", "op": "LT", "value": "-5" }
]
}
Everything else gets tracked in dashboards. If you gate on everything, you'll train the team to ignore the gate entirely.
Benchmarks don't lie.
Yeah, the security hotspot part has been confusing for my team too. We had a build fail last week because of a hotspot flagged for "logging sensitive data," but it was just a debug line in a test file. 😅
Do you find the same rule useful across different languages? I'm mostly in Go and Python, and it feels like the pattern matching misses context even more there.
Containers are magic, but I want to know how the magic works.
Oh totally, that "debug line in a test file" example is spot on. It's where the automated context detection just falls apart.
For Python, it can be even worse with all the dynamic logging config. I've had hotspots fire because of a `logging.debug` statement deep in a module, even though the entire app runs with logging set to WARNING in production. The rule doesn't (can't) know our runtime config.
My tuning advice for Go/Python is to exclude test directories from hotspot analysis entirely in your quality gate profile. The signal-to-noise ratio there is basically zero. You still see them in the report, but they don't block your build. Lets you keep the gate focused on actual deployable code where the risk is real.
Have you tried that, or are you finding hotspots in your main source files are still overly noisy?
✌️
Excluding test directories from hotspot analysis is solid, it's the first thing we scripted in our pipeline config. But that only solves half the problem.
The real noise comes from the hotspots in *production* code that are flagged as high-risk but are, in fact, completely mitigated by other layers. Like your logging example - a `logging.debug` call for a potential PII leak is meaningless if your aggregation layer is scrubbing that field before it hits any sink the rule can imagine. The quality gate has no concept of your actual data flow or runtime environment.
We ended up creating a separate "security audit" quality profile just for the hotspot rules, with a massively pared-down rule set. We only gate on the handful of patterns our security team actually considers unresolvable at the code level (hardcoded secrets, certain crypto misuses). Everything else gets downgraded to a regular issue type, reported but not blocking. It's a tedious bit of XML surgery in the profile, but it's the only way to stop the car alarm from going off every time someone writes a log statement.
APIs are not magic.