Develop and feature branch reporting different code coverage. Upon looking at scans, develop appears to be reporting lines of cold that have not been modified as new code that does not have code coverage. This causes the feature branch to pass sonarqube gates, but upon merging to develop, develop will treat unmodified code lines as new code and fail the build due to insufficient coverage. In all cases, scans were run with the feature branches that were caught up with develop. Issue has been observed when scanning NPM code.
Steps to reproduce: This has been occurring intermittently and we have not isolated the cause.
Welcome to the community!
When you say the lines haven’t been modified… do they show up in SonarQube with a yellow highlight? If you click the left margin to get ‘blame’ information, do you see a date that’s old or within the New Code Period?
Off-hand my guess would be that a “helpful” process is modifying whitespace and so invisibly “changing” the lines.
The housekeeping feature purged the log from the most recent time this happened, but for the last time this happened that I observed:
The code shows up with a yellow highlight with a blame information that is outside the New Code Period. This happened with an older version of Sonarqube, but appears to be happening after updating to the latest 8.9 version as well.
The next time this happens, it will be interesting to know:
- Is there a yellow (new code) highlight on the line?
- When you click in the margin next to the line to see the blame data, what is the date on the line?
- When does your project homepage say the New Code Period started?
Sorry, it took awhile before this popped up again!
- The scan on the feature branch showed that there were no new lines of code and marked the branch as passing
- On merging the code into develop, the new lines of code are now recognized by sonarqube as lines that need coverage. The lines are then marked as having insufficient coverage and our develop build fails.
- The code is a typescript package scanned using sonarscanner version 184.108.40.2062 and sent to a sonarqube instance running Version 9.0.1 (build 46107)
I don’t supposed you still have access to screenshotting this?
I’m not sure I can get screenshots of this easily without security approval, but this issue did pop up again and I noticed something interesting: the “new code period” between develop and the PR branch did not match up. Develop (the baseline branch) stated the new code coverage period started on June 22, but the PR thought that the new code period started on August 19 (the day the branch was created and scanned). From my understanding, the new code period should be compared against baseline, should it not? Is there a setting that needs to be set that is missing?
It sounds like it’s working as expected. From the docs:
Reference Branch – Choose a specific branch to define your New Code. Any changes made from your reference branch are considered New Code.
So it’s not about matching the reference branch’s dates, but about comparing the code against that branch. And in your case, the New Code Period can’t start on 22 June since the PR/branch didn’t exist then.
From those docs:
" * Previous Version – Define New Code as any changes made in your project’s current version. This works well for projects with regular versions or releases.Available at the global, project, and branch level."
Is that the configuration I would need to use in my use case instead?
I’ll be honest and say that without screenshots to orient myself, I’m having a little bit of trouble keeping up.
The Previous Version setting is best used within a main or release branch where the version number increments on a (semi)regular basis. In that case, you’re looking at everything that changed since the last release as ‘New Code’.
For feature branches (and I’m not sure at this point whether you were talking earlier about feature branches earlier or not) it’s probably best to use a reference branch. And unless your feature branch starts at the same time your reference branch does, you’re still going to see that date mismatch you observed in your 24 Aug post. And that’s perfectly normal and to be expected.
Does that help?
Yes, that does help. We currently use a mainline branch that increments a version when feature branches are merged in. It sounds like previous version is closer to what we need, settings wise. I’ll test with the settings and documentation you provided.