Branch analysis slips issues to default branch

Version: Enterprise Edition Version 8.4.2 (build 36762)

We analyze each branch (using branch analysis) before merging to the default branch through a PR. Each reviewer looks at the sonar analysis to ensure no failing quality gate issues are merged. The problem is, that it happens that the branch has a “passed” but after the merge the default branch got a “fail”.

The issue is present on the feature branch, but not detected as “new code” and therefore not taken into account to calculate the quality gate.

Is this a glitch/bug/defect? Or is it something that needs tweaking from our side?

Here is a function that was present in the default branch but was changed on the feature branch, so much that it fails on the cognitive complexity rule.

Hey there.

Indeed, the issue doesn’t technically involve a line of code that was changed in the pull request (it’s reported on the function), it’s not shown in the context of the pull request analysis.

FR-9, if ever taken up, would address this limitation. I’ll link this thread on that ticket.

Hei Colin

I was afraid that you were saying something like that. But thanks for clarifying it for me.

For us FR-9 would be very much desirable. Should i vote for it? :slight_smile:

Hey Louis.

Can’t hurt!

But at a second glance, I am actually a little perplexed – I oversimplified things earlier:

It’s not precisely a line of code, but an issue location that needs to be involved for an issue to be raised in a pull request, see below:

Indeed – the issue here is raised in a pull request without a changed line.

Just to make sure it’s clear – are you using Branch analysis (passing sonar.branch.name) or Pull Request Analysis (passing sonar.pullrequest.* analysis parameters). You’ve mention branches and pull requests, but also branch analysis (and some users don’t make the distinction), so let’s clear that up!

Hi Colin

Yes, i do not distinguish between branch and pull request analysis. We use Azure DevOps Server (on premise) in conjunction with the SonarQube extensions (SonarQube - Visual Studio Marketplace). We do not explicitly set either sonar.branch.name nor sonar.pullrequest.*, it is all magically taken care of!?

How can i check if we are using branch and/or pr analysis?
I think we are using pr analysis, as the scanner outputs
ANALYSIS SUCCESSFUL, you can browse https://example.org/dashboard?id=OUR_ID&pullRequest=4460

@Colin_SonarSource
I checked the properties files generated by the SonarQube extensions for DevOps Server and it sets sonar.pullrequest.* properties for our PR builds.