CI Stages for Pull Request Analysis

Get help SonarQube
#1

Hi,
We are using Jenkins with GHPRB plugin to run tests on PRs when they get created/updated from Github.
Now we want to run SonarQube PR analysis as well.
Our branching structure is bit different, i.e. 5.0 is our main branch, then 5.5 , 5,4, 5,3 … are our release branches. Master and develop are being used for legacy releases, not active that much.

So do we need to first analyse our main/release branches, like 5.0, 5.x ?
And then do PR analysis ?
So 2 diff stages -

  1. Stage(‘SonarQube branch analysis’) → analyse 5.0 branch
  2. Stage(‘SonarQube PR analysis’) → analyse PR against 5.0 branch ?

I have a bog confusion here, any help/suggestions are helpful.
SQ Version - 7.9.4

#2

Hi @pkazi, welcome to the SonarSource Community!

You’re correct in general: Prior to analyzing the PR, you should analyze any base branches that the PRs might target first. This is crucial to allow SonarQube to analyze the PR branch and have the context of what is new or changed.

I can’t answer in terms of mapping this onto stages or specific use of the GHPRB plugin, as I’m not familiar with it.

FYI, an alternative approach to what that plugin appears to do would be to use the GitHub Branch Source plugin in conjunction with the SonarScanner Plugin for Jenkins. The branch source plugin lets you create multibranch pipeline projects with discovery settings. You could first set it to discover branches that are not PRs, let the jobs run, and then add the discovery of PRs. This approach has the advantage of simplifying your pipeline runs and as a bonus will automatically set appropriate analysis parameters so you don’t have to manually configure the PR id, base, or branch. I recorded a short video about this approach.