SonarQube analysis is done on a feature branch and it showed 104 new lines to cover, which met our quality gate requirement of 85% coverage on new code.
After merging to develop branch and triggered the analysis, it shows only 9 new lines to cover instead of 104 new lines as in feature branch, and because of this our quality gate requirement is failing.
I’m struck by the fact that the list of files in the branch is longer than the list of files in develop. Do those other 2 files still exist in develop?
Hi,
The criteria for “new lines” is different between ‘develop’ and the P/R. In the P/R, the diff is given by git. In ‘develop’, the changed date of each line (normally as provided by git) is compared with the start date of the New Code Period, which in your case is the time date when SQ detected the version ‘5936’.
Does that help understand what’s going on?
@dmeneses, in order to overcome this issue we tried git rebase so that older lines commits in the feature branch are treated to be new ahead of develop branch commits.
Base version on develop branch is 6044.
Ran the analysis on the feature branch and it shows 29 new lines to cover of which 26 are in home.component.ts
The discrepancy I see only in home.component.ts where PR/feature branch is showing 4 “Uncovered Lines on New Code” and develop branch is showing 11 for the same. It has 4 uncovered conditions also. This is impacting coverage in develop branch. Trying to understand why it added previous uncovered lines and conditions as new lines.
@arohithr8 If you go to Measures and click on “new lines” and navigate to one of the source code files, you can click on the bar on the left and see what information got loaded from the SCM, including the date and the revision. If this date (or the author date of the revision) is before the start of the New Code Period (in your case, when SQ detected 6044), the line won’t be “new”.
Note that a rebase might change the commit date but won’t typically change the author date and git’s blame relies on the author date.