I have set up SonarQube to scan any feature branch that is updated in our project (e.g: the scan is run automatically whenever someone pushes new code).
the “new code period” is set to the default, which is “previous version”.
This flags up issues in case the quality gate is “broken”, but in case another scan is executed, no issues are flagged since the delta between last 2 scans does not result in any new issues.
Is this by design? how can i overcome this? or is this setting of “new code period” not suitable for our scenario ?
If this is correct, then you need to take a look at what you’re passing for sonar.projectVersion. If you’re passing a build string, then you’re going to have a new value and thus a new version with each analysis. I.E. you’re going to be resetting the New Code Period with each analysis.
If you really need build string associated with the analysis, use sonar.buildString from that (you’ll be able to retrieve it in Activity Page mouseovers and from the API) and use sonar.projectVersion for the first couple places of the string that don’t change from build to build.
E.G.
full build string/version: 8.4.0.1024 => sonar.projectVersion=8.4.0 sonar.buildString=1024
If I’ve guessed wrong here, let me know (with maybe a few more details! ) and we’ll try again.
So your assumption was correct. But now i am facing a different issue - when should we update our projectVersion parameter?
We work with distributed teams, all working on 1 project. how often should we “bump” the project version to a new version? and what effect will that have?
Our product is a mobile game so we release an update every X days and number it accordingly. Should we modify projectVersion in correlation with our releases?
Yes, that’s the general expectation: that your version will be incremented with each release. This goes back to a core part of the Clean as You Code concept: what you’re trying to do is make sure each release is at least as good quality-wise as the last. So your New Code Period is since the last release and it’s the changes since that last release that get the most intense scrutiny.
so we had 50 open bugs in version 1.0, we did not handle them, but we now released 1.1.
In my scan it shows 0 errors (since there are no new bugs between 1.1 and 1.0).
Well, they should still be there under the ‘overall’ reports. If you’re on a more recent version of SonarQube then you’re not being presented those overall numbers by default. You’ll have to pick the Overall Code tab to see them:
) and we’ll try again.