Github check (Quality Gate of new coverage) fails after refactiong untested classes

We’re actually using the new quality gate of new code coverage in our projects, and there we had to rename classes with too little test coverage. Now the check does not go through in GitHub, because it is recognized as new code instead of old changed code. We did not found any possibility to accept the new state in sonarcloud, just like it is possible for issues themselves by marking them as false positives or won’t fix. Is there a way to solve this problem apart from re-projecting and turning off check.

Hi Enes,

We do detect file renaming to track the state of the issues (like won’t fix) present in the file before it was renamed.

However, when it comes to classifying the code as new or not new, SC relies solely on the information given by the SCM (when possible). Then, it applies the quality gate on lines of code classified as new.

There is currently no way to “mute” new coverage of files that were renamed.

Hi @oezelenes, can you specify the SCM you are using (Git, SVN, none)?

Hi, thanks for responding. We’re using Git.

What if you run git blame on the offending file? Does Git correctly detect the file move, or does it report all lines as recently changed?

It looks like git has noticed the change correctly.

image

Any chance you could give me temporary access to your project on SonarCloud (my SonarCloud username is julienhenrysonarsource@bitbucket)? If it’s not possible, can you check that blame data is correct in the offending files (especially date):
image

I have checked it and SonarCloud addresses all lines at the date of the refactoring.

image

We also added you temporarily to members. Organization: retest

Hi @oezelenes

Thanks for giving me access to the project. I see this warning in the UI:

Shallow clone detected during the analysis. Some files will miss SCM information. This will affect features like auto-assignment of issues. Please configure your build to disable shallow clone.

Shallow clone will truncate the SCM history, and that explain why you don’t have the correct date for each line. To fix it, you should configure your CI to fetch the entire Git history (or unshallow). Once it is done, each time you will change a file, the blame will be computed again and that will fix data.

If you want to fix data for all files at once, you can temporarily add the parameter -Dsonar.scm.forceReloadAll=true to the scanner, and then next analysis will blame all files. Don’t forget to remove the parameter after that.

1 Like

Hi @Julien_HENRY

You were right, after I have disabled the shallow clone it worked properly.

Thanks for your help.

Great, thanks for letting us know.