Limit quality gate scope to Pull request delta

[samuelson (Josh Samuelson)]

We’re attempting to use Sonarqube quality gates to block PRs that contain new bugs from being merged.

There isn’t much more to say, but let me be explicit so there is no confusion.

1. Developer creates branch from “master” and makes some code changes
2. Developer pushes branch to github and initiates pull request
3. Jenkins tests pull request including triggering sonarqube testing.
4. Sonarqube does analysis on the new code in that PR and fails the quality gate if that code would introduce a bug.

I had assumed that this would be the default behavior: only fail on the code that’s actually changed in that PR, but it seems that any bug that previously existed in the repo is also included.

I’ve looked all through the documentation and read all the threads I could find on this topic, if this has already been covered please point me to the right documentation. I feel like I’m missing something incredibly obvious here.

• SonarQube Developer Edition 7.9.1
• Jenkins SonarQube plugin 2.8

[dmeneses (Duarte Meneses)]

Hi Josh,
The behavior that you described is the one I would expect in SQ v7.9.1.
Only new bugs introduced in the P/R should show up. If that’s not the case, perhaps the target of the P/R wasn’t analyzed or wasn’t up to date in SonarQube?

One of the ways SonarQube detects “new issues” in the P/R is by comparing issues in the P/R with issues in its target branch. So if the target branch isn’t up to date in SonarQube some issues might be missing there, making them appear in the P/R.

[samuelson (Josh Samuelson)]

Thanks for the reply I’m still trying to figure this out. I think I might be running into this issue:

PR Analysis Results Inconsistent - results from master branch sometimes included

Hi Melissa, SonarQube knows that your P/R is targeting development because it’s specified in the command line. The problem is that during the analysis it can’t find that branch in the local git references. Are you sure that the reference is available the agent? Sometimes, to avoid downloading all branches, agents only fetch the branch being built. You could try calling git fetch --all before calling sonarscanner.

But Jenkins is a bit fiddly to get the branches fetched. I’ll update the thread once I figure out the right Jenkinsfile code.

[samuelson (Josh Samuelson)]

Ok that’s working now I think. I ended up adding some git commands to my test prep script instead of messing with the Jenkinsfile:

git config --global url."git@github.com:".insteadOf “https://github.com/”
git config remote.origin.fetch +refs/heads/:refs/remotes/origin/
git fetch --all