Pull request new code not being scanned

Hi,

We’re using:

  • SonarQube Developer Edition 7.9.1 with the latest version of each plugin.
  • Bitbucket Server 6.3.1
  • Jenkins 2.172 LTS
  • Gradle 4.10.2
  • Kotlin 1.3.11

Issue in short: when we update a pull request and create an issue, this issue is not reported by SonarQube on the pull request.

Scenario:

  • we create a branch from the master
  • we create a pull request from this branch to the master
  • we introduce, for test purpose, a high severity issue like:
   val test = "xxx"
+  val yetAnotherPassword6 = "zzzzz"
  • the pull request is scanned by Jenkins using:
    ./gradlew \
       build jacocoTestReport sonarqube \
      -Dsonar.pullrequest.bitbucketserver.project=CLOUD \
      -Dsonar.pullrequest.bitbucketserver.repository=bitbucket-project \
      -Dsonar.pullrequest.key=40 \
      -Dsonar.pullrequest.branch=master \
      -Dsonar.pullrequest.base=feature/410-sonarqube 

The PR entry is correctly visible in SonarQube, but NO issue is detected :frowning:

We’ve performed the tests several times, adding more and more issues, still nothing.

We bought the Developer Edition especially for this feature and right now, the PR quality gate is pretty useless.

It’s likely an error on our side, so any help would be very much appreciated.

Best regards,
Damien

We have maybe a simpler use case:

  • create a branch from the master
  • add 1 line with a high severity issue
  • scan the branch
  • the short lived branch does not show the issue

However, we get the following warning:

Some Quality Gate conditions on New Code were ignored because of the small number of New Lines

So, are both issues related to https://jira.sonarsource.com/browse/SONAR-10485 ?

If yes, this is REALLY blocking for us, because it would mean that we can easily introduce a high severity issue, without any (automated) control until we reach the main branches?

Thanks for any help about this,
Damien

Hi Damien,

As I understand it, you’re reporting multiple problems here:

  • my PR was not decorated(?)
  • expected issues weren’t raised
  • I get a warning on the branch homepage

It’s really best to keep it to one issue per thread, but I understand that you might not have realized it was multiple different things so I’m going to try to address them all here. But if we have to go in-depth, we’re really going to need to split these topics.

Okay, first item…

You’re passing

...
   -Dsonar.pullrequest.bitbucketserver.project=CLOUD \
   -Dsonar.pullrequest.bitbucketserver.repository=bitbucket-project \
...

Those values must be set server-side. PR decoration is triggered asynchronously from the server at the end of analysis report processing, and those analysis parameters are no longer in scope when decoration would happen. So you’re looking at a PR analysis with no information about where decoration should take place. Therefore, it doesn’t.

2nd item…
What rule do you expect to raise an issue on the code sample you provided? Nothing is jumping out at me.

3rd item…
The warning you’re seeing on the homepage is purely about metrics in the quality gate and is entirely unrelated to issues. All new issues will always be reported, regardless of how many or how few new lines there are. But when you have only 1 new line and it’s uncovered, then you have 0% coverage. If that line is difficult to cover, then you’re stuck with un-mergable/releasable code. So we don’t fail the quality gate for coverage (or duplications?) when there are fewer than 20 new lines.

 
Ann

Hi,

Thank you for the detailed answer. We’ve been struggling on our own for some time with all those issues and I’ll try to focus on the first item (PR decoration missing).

  1. we’ve set sonar.pullrequest.bitbucketserver.project and sonar.pullrequest.bitbucketserver.repository server side
  2. we know pass -Dsonar.scm.revision=<commit> where <commit> is the commit of the HEAD, plus the required options as mentioned in https://docs.sonarqube.org/latest/analysis/pull-request/

Still the link is not established. At least for this project, for other, it works like a charm :frowning:

I was wondering about the sonar.scm.revision parameter: it’s not documented anywhere and when we remove it, we had errors like the “Git commit was missing”. Is that something we really need to do?

Best regards,
Damien

Hi Damien,

Regarding sonar.scm.revision, I can’t give you any details because I don’t think I’d even heard of it before this thread. At a guess you’ve sussed-out one of the internal parameters normally set by analysis. If I’m correct, the fact that things go sideways when you don’t set the value manually means that the underlying parameters still aren’t correct.

So let’s talk about your checkout. Are you analyzing the PR branch or a merge branch? Also, you’re not doing a shallow clone, are you?

 
Ann

Hi Ann,

We scan a PR and the checkout is performed by Jenkins using the checkout scm pipeline step. It’s a full clone and in some cases, it’s a fast-forward merge, in other cases, a regular merge (without conflict).

Damien

Hi Ann,

I’ve put more details below.

The checkout operation, orchestrated by Jenkins, looks like:

[2019-08-14T09:08:23.999Z]  > git config core.sparsecheckout # timeout=10
[2019-08-14T09:08:24.001Z]  > git checkout -f fb9a6b8103870138804fa1edf4f1275d3ae6d43e
[2019-08-14T09:08:25.935Z]  > git merge 8fa8492ea40707e706586407c60bebfd84807309 # timeout=10
[2019-08-14T09:08:25.985Z]  > git rev-parse HEAD^{commit} # timeout=10
[2019-08-14T09:08:26.031Z]  > git config core.sparsecheckout # timeout=10
[2019-08-14T09:08:26.033Z]  > git checkout -f fb9a6b8103870138804fa1edf4f1275d3ae6d43e
[2019-08-14T09:08:26.756Z]  > git branch -a -v --no-abbrev # timeout=10
[2019-08-14T09:08:26.842Z]  > git checkout -b PR-4063 fb9a6b8103870138804fa1edf4f1275d3ae6d43e

and the options passed to SonarQube are:

./gradlew sonarqube -Dsonar.pullrequest.bitbucketserver.project=MY_PROJ -Dsonar.pullrequest.bitbucketserver.repository=my-repo -Dsonar.pullrequest.key=4063 -Dsonar.pullrequest.branch=bugfix/INT-712-xxxx -Dsonar.pullrequest.base=maintenance/5.7 -Dsonar.scm.revision=8fa8492ea40707e706586407c60bebfd84807309 -Dorg.gradle.jvmargs=-Xmx6144m --profile --info --stacktrace --console plain

What I understand is that the sonar.scm.revision property will be correct in case of fast-forward merge, not in case of a merge.

When we get rid of it, we have an other error in the SonarQube PR scan (that the commit was not found).

For now, I’ve gotten rid of the sonar.scm.revision flag to start from a clean slate ; but I would need to test both fast-forward merges and regular merges.

Hi,

I believe it’s the merge that’s the problem. It creates a new commit number that doesn’t exist on the GH side. Can you try it without, and drop the sonar.scm.revision parameter?

And again, there’s no real point in passing these parameters on the analysis command line:

-Dsonar.pullrequest.bitbucketserver.project=MY_PROJ
-Dsonar.pullrequest.bitbucketserver.repository=my-repo 

 
Ann

Hi Ann,

Parameters dropped ; we try again.

Damien

Hi Ann,

When we remove the sonar.scm.revision parameter, we get the following error in Sonar:

image

Do you know where we could find more information about this error?

Thanks,
Damien

Hi Damien,

Are you able to find that SHA on BitBucket? Or is that a merge commit SHA?

 
Ann

Hi Ann,

This is a merge commit SHA ; not available in Bitbucket.

Damien

Hi Damien,

That’s your problem. You’re trying to decorate a commit that doesn’t exist. So you need to either not perform the merge, or perhaps try this community recommendation:

 
Ann

Hi Ann,

We’ve indeed tried this - by using the Git commit of the HEAD. But this does not work when this is a local merge, and not a fast-forward.

We’re now trying to get the commit of the source branch for a pull request, which should be equivalent.

I’ll post about the result.

Hi Ann,

We have tried to pass sonar.scm.revision being equal to the last revision of the source branch, by taking the value of git rev-parse origin/${env.CHANGE_BRANCH} and it seems to do the trick.

However, we still don’t know why SonarQube needs this property and it’s not documented in https://docs.sonarqube.org/latest/analysis/pull-request/.

Damien