Linking security hotspot review between PRs and branches

Currently in Sonarqube when we create a PR we end up having a branch and a PR portion of the project. This reflects what our project looks like in Jenkins - we have a branch and a PR based build.

The problem I have is when we have a security hotspot for review. You have to review the same hotspot in two places in order for both the branch and the PR build to pass the quality gate. This is a duplication of effort I would like to avoid.

It would be nice if Sonar recognised that the hotspot you were reviewing actually applied in two places - the PR and the branch and then allowed the user to say “Apply whatever I am doing to both places”.

Hello @Rob_White,

Interesting case that you are bringing here. What is the version of SonarQube for which you report this ?

  • On SonarQube 8.0 and older (7.9.x and before) the fact that a hotspot has been reviewed should be preserved when merging a PR in a Long Lived Branch
  • On SonarQube 8.1+ the fact that a hotspot has been reviewed should be preserved in all cases after merge (simply because there is no distinction between short lived and long lived branches, there’s only branches).

So the only reason why you would witness the behaviour that you describe is that you are running SonarQube 8.0 or older and you are merging your PR in a short lived branch.
If that’s not the case, please provide more details on your environment and some screenshots.

Olivier

Hi Oliver,

  • Developer Edition
  • Version 8.4.2 (build 36762)

You are correct, the fact that a hotspot has been reviewed is preserved after the merge. However, my problem occurs pre-merge.

Here’s my flow:

  1. User creates a feature branch and makes a commit, pushes up to GitHub and creates a PR.
  2. Jenkins kicks off a build for the branch and a build for the PR. The build has a Sonar stage followed by a quality gate check.
  3. Sonar stage and quality gate fails for both the PR and the branch because of a security hotspot
  4. I review the hotspot in the PR and kick off the build for the branch and PR again. The branch will still fail because the branch based hotspot has not been reviewed. The PR build will now pass.

Now you could say “why build the branch if you have the PR?” - well that’s just how Jenkins works. And it leaves my GH PR with a red cross for the failed branch build.

I can see why someone might not want the PR hotspot review to apply to the branch hotspot but i’d like an option you can check where it’ll apply to both if you want.

Hello Rob,

OK. I get it. Well unfortunately if you analyze both a PR and the branch corresponding to that PR and you review the hotspot on the PR only, then the same hotspot is not marked as reviewed on the branch.
And indeed the reason behind this is that we believe that the pipeline should either analyze PRs (preferably, if PRs are used by developers) or feature branches (if PRs are not used) but not both.

I understand that selecting branches or PR (exclusively) in jenkins may not be that easy (since you still have to analyze main branches (master, develop, maintenance & release branches)). I see 2 different options:

  • You leave your pipeline as is and developers should simply ignore the (feature) branches analyzed in SonarQube. These branches are continuously deleted as they are merged and no longer analyzed, so you, at all time, should only have a small number of these branches visible from the SonarQube branch menu.
  • Either you have good branch naming conventions and your pipeline should check the branch name to determine if the branch should be (built and) analyzed or not
    This option is obviously better because it makes it clearer in SonarQube AND it saves processing on your CI (no build of the feature branches, only PRs).
    And indeed it requires to create a PR almost as soon as the branch is created so that the code of the branch is analysed as early as possible in the development of that branch

Olivier