Use the newly submitted code of a new version of release as the baseline to analyze code coverage

Please provide

  • Operating system:Windows 10 X64
  • Visual Studio version: VS2019
  • SonarLint plugin version:
  • Programming language you’re coding in: .NET
  • Is connected mode used:
    • Connected to SonarCloud or SonarQube (and which version): SonarQube

And a thorough description of the problem / question:
We have a project published according to a release, and each release requires statistics on the issue data and unit test data of the code submitted by the current release. The project is developed by .NET and the .NetFramework version number is 4.6.0. We want each release to only use the code submitted by that release as the baseline to analyze data related to issues and code coverage, the previous release submitted code will not be included in the statistics. How should we set properties such as baseline and new code in this situation.

Hey there.

Everything you’re describing should work by default in SonarQube, or with minimal configuration

  • You have the branch containing your previously submitted code (the code currently in production) set as the reference branch
  • Your Quality Gate conditions (set only on New Code) cover the code that has changed in your new release

Hi Colin,
Thanks for your reply, could you give a details description on how to configure this situation in SonarQube? Does your answer mean that I will create a new release branch and use this new release branch as the baseline? As I am the new user of SonarQube, your help will greatly inspire me in using SonarQube in the future.

I appreciate that you want a step-by-step guide, but you also need to try it out for yourself, reference the documentation and document what has/hasn’t worked! This is a community forum, not paid support.

Yes – in order to use some code as the baseline for another set of code, that code will need to be contained in a branch that is used by SonarQube as a reference branch. This probably already maps to something you’re doing to indicate what code is in production, or which code contains a specific version.