Sonarqube: Diff two branches / tags / SHAs

  • which versions are you using (SonarQube 8.9.1.44547)
  • I like to script a way to find the difference in code smells between two branches (or SHAs)
  • On a Linux box I tried this bash script sonar_diff : and run sonar_diff workgit master my_sidebranch.
    I have the sonarqube server running on https://sonarqube.services and the project is called workgit
#!/bin/bash
#Save as sonar_diff

branch1=$1
branch2=$2

echo "comparing ${branch1} and ${branch2}"

curl "https://sonarqube.services/api/issues/search?componentKeys=workgit&branch=${branch1}&ps=499&resolved=false" > branch1.txt
curl "https://sonarqube.services/api/issues/search?componentKeys=workgit&branch=${branch2}&ps=499&resolved=false" > branch2.txt
jq . branch1.txt > branch1.json
jq . branch2.txt > branch2.json
meld branch1.json branch2.json

I see that it is not feasible to diff the two branches - since the keys appears to be changing per branch.

This topic has been raised earlier:

For the project in question it is poisoned with ~400 warnings, so it is not fun to find 10 new warnings out of 400 … or 410.

The only viable approach I have now is to look at the sonarqube webpage and see which code smells are made within the last few hours - right after pushing the branch. That is not sufficient, but a poor mans version of something usable…

Ideas - or directions - would be really welcomed

Hi,

If you really want to do this…

First, I need to point out the option to set the New Code Period of one branch based on another branch. There are a few… quirks in the algorithm that have been improved since 8.9, but the ability is there, and should help you toward your goal.

However, based on your URLs, I’m guessing you’re using Community Edition, and you would need a commercial edition($) to use it.

So based on what you apparently have…

Your search URLs aren’t limited by types, which may narrow the result set and make things easier.

From there, you’re going to need to apply essentially the same algorithm analysis itself employs:

  • if the issue is on the same rule, with the same line number and with the same line hash (but not necessarily with the same message) > MATCH
  • detect block move inside file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) > MATCH
  • on the same rule, with the same message and with the same line hash (but not necessarily with the same line) > MATCH
  • on the same rule, with the same message and with the same line number (but not necessarily with the same line hash) > MATCH
  • on the same rule and with the same line hash (but not the same message and not the same line) > MATCH
  • is there a matching CLOSED issue > MATCH and Reopen

(I recognize you can’t feasibly do block move detection. I assume those cases can be identified manually.)

 
HTH,
Ann

dear @ganncamp I am a paying customer (Developer version)… a happy one.
Is there a newer LTS where the relevant features are in?
I am an LTS fanboy but if you say that there is golden stuff in 9.5 I can upgrade soon.

Changes to how I can control how/what “New Code” is reported is also very interesting. in 8.9 I almost never use the New Code … but that is another matter.

Hi,

The current LTS is 8.9.8, and it does have the ability to set New Code Period to a reference branch. And, as I alluded, there are some problems in 8.9 related to how new code is calculated when that setting’s used. And it would still be worth trying in 8.9. Maybe you won’t hit the problem situation.

 
HTH,
Ann

1 Like