A SonarQube analysis of a PR is, by definition, only the new code – only the code you want to merge. Once you’ve performed the merge, you can analyze the target branch using branch analysis to get the full picture, but this can’t be done as part of the PR analysis.
I hope this clarifies; let me know if you need more details.
BTW
Before we purchase a license we used sonar 7.6 community with plugin from GitHub. So there was a property sonar.gitlab.all_issues that cover my case. Don’t understand why github plugin works better then newest licensed instance.
Was this vulnerability already in the branch? Or was it introduced by the PR? That’s the critical question in understanding whether it should be found by PR analysis.
Can you zip up the scanner-side logs from the scan of the MR and post them? Feel free to redact any sensitive data. Could you also post a screen shot of the vulnerability on that line of code as shown in the branch scan?
Apologies for the delay on this. I’m seeing the following in your log file:
INFO: SCM collecting changed files in the branch
WARN: No merge base found between HEAD and refs/remotes/origin/master
INFO: SCM collecting changed files in the branch (done) | time=215ms
which makes me suspect you’re seeing something similar to this thread where (in a GitHub context rather than GitLab) SonarQube is not able to determine what are new files. To check this:
Can you go to the Code tab of the PR analysis in SonarQube and check the files there. Do you see consul.py?
Is there anything special about the way you’re configuring GitLabCI to check out your branches?