Run sbt clean compile coverage test coverageReport
Run sonar-scanner -X -Dsonar.projectVersion=BASELINE -Dsonar.host.url=xxx -Dsonar.login=xxx
Go to the newly created project and set the New Code period to BASELINE.
Make some change in your code to cause a code smell. Run the exact same build and sonar-scanner commands. View the project in SonarQube. Go to Overview and it will show the New Code period as previous_version instead of BASELINE.
Run the sonar scanner command again. Go back to the UI and you will see that the New Code period is still previous_version. The problem is that the New Code analysis shows 1 code smell even though no changes have been made since the previous BASELINE.
Go to the Activity tab and mark the first analysis as version “1”.
Run sonar scanner again. Go back to the UI and now it shows the New Code period as BASELINE with 0 code smell.
This is definitely causing a lot of problems for us because we do our quality gates on the pull request branches. So, if pull request 1 has 85% code coverage, pull request 2 has 85% code coverage, etc., eventually all that “new code” dips below 80% and then our quality gate fails since SonarQube is ignoring the New Code period setting. And so “new code” means our first analysis with SonarQube.
I have seen this on both Scala and Java projects. It also seems to be new since we upgraded to SonarQube 7.4.
I know this is a dumb question, but you did “Save” your config change, right?
Which means that you ran two successive analyses with this?
I ask because If you run multiple analyses with the same version string, SonarQube “moves” that version marker to the latest analysis each time. (It’s really a way to keep track of the last use of version X.) So by setting the New Code period to “BASELINE” and then continuously resetting “BASELINE” to the newest analysis, you never allow a “since” period to be established. (Hope this makes sense.)
I definitely clicked Saved. And no worries about asking that question.
And yes, we are resetting the BASELINE each time. This is on a master branch and we do our work in pull requests.
So, if I run 3 analysis and all 3 are set to BASELINE, my expectation is that the New Code is 0 on each analysis. But they are not. The New Code actually accumulates since the first analysis. And the leak period in the Overview displays “previous version” even though I configured it to be “BASELINE”. And at least in this case, the definition of “previous_version” seems to be since the very first analysis.
And then I explicitly mark the first (or any other analysis) as Version 1 (or something else explicit). Re-run analysis. And then everything works as expected.
On pull requests, we set one BASELINE version (typically master) and then do analysis of the pull request code on top of that. In this case, the leak period does seem to show as BASELINE in most (but not all) cases. I have not had a chance to dig any deeper into this case.
So first, your setting your New Code period to the name of a version that’s not … “previous” is I think throwing things off.
I think what’s happening when it displays “previous_version” as your New Code period is that you’re falling back to the global default because the value set at the project level doesn’t make sense as a New Code period. We did some work in 7.4 (SONAR-10555) to error-out analysis when the New Code setting doesn’t make sense, but I guess you’ve found a hole in the code.
If I’m correctly reading your initial post, the first analysis doesn’t have a version string, so I think it gets defaulted to something like “no version” or “not provided” or … something like that. At any rate, it ends up with some version string that’s not “BASELINE”. So then you change your version string to “BASELINE” and default (as previously discussed) to a previous_version new code setting, and so you do rack up new lines versus your very first analysis.
Actually, the first analysis does have sonar.projectVersion=BASELINE. I am not changing it to BASELINE. It is uploaded to Sonar with a version of BASELINE. I am aware of SONAR-10555. But I don’t think that is the issue here.
And the first analysis also auto-creates the project. So, the project is initially created with a New Code period of previous_version because that is the default. Perhaps it is analyzing it before the version of BASELINE is being set?
So, these are the steps:
Upload analysis with version = BASELINE. This autocreates the project.
Manually modify the New Code period in the project admin from the default of previous_version to BASELINE.
Upload another analysis with version = BASELINE. In the Overview tab, despite what the project settings says, it displays the New Code as previous_version.
Manually set the first analysis to version “1” or really anything.
Upload another analysis with version = BASELINE. In the Overview tab, it now says that the New Code period is BASELINE.
You’re getting odd behavior because you’re doing something weird. As previously stated, with each analysis that passes the same version string (“BASELINE”) we move that version string forward to the current analysis. Any given version string is attached only to the most recent consecutive analysis that used it. Your first analysis no longer has the version string BASELINE, only your most recent one does.
So then when you set your New Code period to your current, floating version string, you say “compare this code to”… “this code”, essentially. From my testing, what actually appears to be happening is that each analysis is compared to the immediately previous one. (I guess the version string is moved as a last step.) The New Code period labeling is admittedly glitchy here. SONAR-11492 should fix it. But I don’t see anything else that needs addressing.