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.
full build string/version: 18.104.22.1684 => 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.
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.
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: