We are seeing issue with the way Sonarqube is working to recognize and pass/fail the PR based on the quality gate check which is enabled. The way we want to read the new code is really any new lines that get added as part of that PR should really be the new code. It looks like sonarqube is reading new code quality check of a PR and comparing it with target branch overall code and passing or failing the PR based on that. Hence, we came up with too low numbers in quality check.
Here are sonarqube details:
Version: Sonarqube Enterprise Edition Version 8.9.6
Scanner: Standalone scanner
Plugin: Jacoco 0.8.8
This shows the quality gate that is setup for this project in sonarqube:
Hi Ann, thanks for responding. All I want to do is block Pull Request merges if the code coverage on new code of the PR doesn’t meet a threshold as mentioned in quality check. As per our understanding, it looks like (hope we are wrong) PR new code coverage is being compared with overall code coverage of target branch. Because of this understanding, we have enabled the quality gate check for 45% instead of wanting to meet 60%.
As per how we have configured here, please let us know if it is correct and if at all this is correct, what should be the expected behaviour.
In that case, we don’t see the right results. Can you help us understand what is the new code definition as per the settings we have done? Does it mean any change done on top of previous version of source branch? Meaning… if source branch is at 70% new code coverage, any change done on top of that code is meant as new code?
Currently we haven’t configured long lived branch specific setting… All the branch names you see above are required to long live. They are infact mini projects for this master project in the same repo. We haven’t configured individual project for each of these mini project and there is one sonar-project.properties file which is being referred for every PR which runs for each of these long lived branches.
I am supposing if I would need separate projects for each of these branch scans so i could apply new code settings in a way that new code refers the previous version of this long lived branch.
Kindly advise. Hope I don’t cause too much confusion.
How is the code coverage being calculated in this case?
I have added this line in Prepare analysis step- sonar.newCode.referenceBranch=$(sonarBranchName)
I don’t seem to understand what is causing 21k lines of code when the line changed (which should be new code) is just 1 in source branch. I am starting to think my definition of new code might need some change. Please guide.
Your middle screenshot cuts off the tabs at the top. I guess they also say the New Code Period started yesterday? I think it would be helpful to go to the Measures page and look at what SonarQube is seeing as New Code. See what you can identify as non-new that SonarQube thinks is new and then trace back to the history of the files / lines in question. When was it they actually changed last, and by what route did those changes get into your branch.
By SonarQube 8.9, there are only long-lived branches.
Are you saying the entire file is marked as new code, when it should be only a few lines in the file?
Can you provide details of your checkout? Also, is it possible you have some automation in your process that alters whitespace? We’ve seen this sort of thing before when E.G. the IDE is inserting tab characters and they’re automatically being changed to spaces somewhere in the process.
Again, can you see what your SCM has as the history for the “not-new” lines in the file?
Sorry, I’ve never seen that error before. I don’t think it’s coming from SonarQube.
You’re doing a fetch and checkout rather than a clone. The docs are explicit that a “full clone is required for this integration to be able to collect the required blame information”. I’ve been going in circles in the Git docs trying to figure out whether or not your sequence of operations puts the required history in place to properly detect new code. It’s possible this will work properly if you --unshallow your fetch. Otherwise, you may need to switch to the expected clone operation.
I tried doing ‘git fetch --unshallow’ and it gave me this error: Initialized empty Git repository in /agent/_work/2/s/test1-bpnextgen-sapcommerce/.git/ fatal: --unshallow on a complete repository does not make sense
Here is the exact updated command(let me know what is the exact update required):
I noticed something that I might be useful to check to understand why PR is comparing old lines and old code is probably because it reads the previous version as too old.
Here is a screenshot from Activity tab and it shows ‘new code period starts here’ on an analysis done on the day project was onboarded on sonarqube. So, although the pull request scan should really consider new code compared to previous version of target branch, as the previous version of target branch is really old, it is considering too many lines as new code. Please advise. Is this the reason for my incorrect new code calculation in PR scans?