Pull request analysis sometimes doesn't flag issues

Hi Team.

I have a question regarding SonarQube’s Pull Request analysis.

I performed an analysis on a Pull Request from the develop branch to the release branch with the following settings:
sonar.pullrequest.branch=develop
sonar.pullrequest.base=release

There is code in the develop branch that should be flagged as an issue,
but the Pull Request analysis did not flag it, and the analysis passed.
However, after merging into the release branch, the branch analysis for release failed and the issue was flagged.

What is the difference in cases where the Pull Request analysis does not flag code as an issue even though it should?
Is there a specification where issues are not reported if the conditions for passing the Quality Gate are met, even if there are issues?

The environment is as follows:

SonarQube: 10.2.1 Deeveloper
Source Code: Java/Kotlin project and Objective-C/Swift project
GitHub Enterprise
The Quality Gate being used is shown in the attached image.

Hi,

PR analysis only raises issues on changed lines. There are a number of cases where changes in one line can cause new issues to be raised in an untouched line.

Were the issues raised after merge raised on lines that were changed in the PR?

 
Thx,
Ann

Hi

This happened with a line that was changed in a PR.
I think this will become an issue at the PR analysis stage.
The code I changed was not flagged as an issue, so I merged it.
But the branch analysis flagged the changed line as an issue.

Hi,

Can you share what language and rule we’re talking about? The rule ID will look like S1234.

 
Thx,
Ann

Hi

This occurs in swift:S1186 and java:S2259.

I’ve attached a screenshot of when it actually happened.

Hi,

Thanks for the screenshots! Can you share the analysis log from the PR?

 
Thx,
Ann

Hi

I was not sure what the analysis log refers to, so I am attaching a file that I think is relevant.

  • ce.log
  • gradle_task.log
  • scanner_context.txt

I have masked items that I consider confidential with “xxxxxx”.

ce.log (9.0 KB)
gradle_task.log (21.0 KB)
scanner_context.txt (6.9 KB)

Hi,

As it turns out, I was looking for the Gradle log. Unfortunately Gradle’s default logging level isn’t all that helpful. What this shows is an exception during analysis, but that seems unrelated to the initial report here, which is that PR analysis is missing some issues.

Did this Gradle log come from a PR analysis that missed some issues?

And if so, can you add a --info flag to the Gradle command and provide the resulting log for re-analyzing that PR?

 
Thx,
Ann

Hi

This gradle log is from a sample project in a similar situation.
I confirmed that the same thing is occurring.

Thanks for checking the log.
I added the --info option and ran it again.

gradle_task.log (139.7 KB)

Hi,

Thanks for the log. With it, I’m revising my earlier opinion that the stacktrace was a red herring. And… you say that after merge, analysis runs without error and raises issues?

At this point I would normally flag this for the language experts, but refreshing myself on your initial post I see that you’re on 10.2.1, which is EOL. Can you upgrade to 10.6 and see if this is still replicable?

 
Thx,
Ann

Hi

you say that after merge, analysis runs without error and raises issues?

Yes.

Since we update based on the LTS (LTA), we cannot update to version 10.6.

The reason we are currently using version 10.2.1 is that there was a critical bug in iOS analysis in version 9.9, and we specially updated to version 10.2.1, which includes the fix to avoid that issue.

The current issue is not critical, but I asked this question because I would like to explain to users whether it is a bug in version 10.2.1 and which version contains the fix.

Hi,

You’re already not on the LTA. Which means you’re on an EOL version. I urge you to take the 10.6 upgrade. Unfortunately, I’m not sure we can help you with this on the 10.2 version.

And if you really can’t take the upgrade, the new LTA is expected in November.

 
Ann

Hi

Understood.
I will wait for the next LTA, hoping that the necessary corrections have been made to achieve accurate analysis results.

Thx.

Hi

After that, but in a different environment, we prepared a SonarQube 10.6 environment.

I tried to create a Pull Request with the code that would become an issue under the same conditions, but no issue was created.

Attached is the gradle log and a capture.

gradle_task.log (117.8 KB)

Hi,

To be clear, you’ve set up exactly the same scenario in your 10.6 environment:

  • same base branch analyzed
  • same PR analyzed

And again, PR analysis didn’t detect your newly-introduced null-pointer dereference?

 
Thx,
Ann

Hi

PR analysis didn’t detect your newly-introduced null-pointer dereference?

No, the issue was not detected.

I am a little concerned about this.
In the GHE PR, the new line is “3 New Lines”.
I am concerned that the new line is “0 New Lines” on SonarQube.
Gradle log outputs “java file 1file” and “kotlin file 1file” as if they were analyzed.
If this log information is correct, it seems strange that the SonarQube screen should show “3 new lines”.

Hi,

Could you clarify this?

Where, exactly, are you seeing it report “3 New Lines” and where are you seeing 0? (Screenshots might be helpful…)

If 0 new lines were detected, that would explain why your issue wasn’t raised: PRs only report issues raised in new code. So this may just be about getting the checkout right.

 
Ann

Since the experiment was carried out under the same conditions, the PR is the content of the capture.
“0 New Lines” is the part framed in red in this capture.


Hi,

Thanks for the screenshot.

Can you provide your full analysis log, please?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
Ann

Hi

Sorry for the late reply.
I am attaching the full log file with the --debug option.

raw-gradle-output.log (4.2 MB)