My team is convinced that SonarCloud is, from time to time flagging issues as “new” on C++ code that has not been recently modified.
The issues are valid, and correct, what is perplexing is why is SonarCloud identifying this code as “new”?
I looked at one issue reported today. The error message follows:
Make sure that moving an object of class "Task" is "noexcept" (for instance, by ensuring that moving base classes and member data is "noexcept"). Move and swap operations should be "noexcept" cpp:S5018
This was reported in a file called task.h. This file has not been modified for many years. Interestingly, an associated file called task.cpp (in the same directory) was modified in the same commit that reported the failure. What’s going on here? Please help me get to the bottom of why SonarCloud thinks the .h is new code in this situation
Hi @boinst ,
To understand the behavior of your analysis, I suggest 3 avenues:
-the configuration of the new code period
-the evolution of the quality profile applied to your project
-the source exclusion/inclusion parameters which you can consult in the background tasks of the project concerned.
Hope it’s help
Are you analyzing your C++ using a compilation database or the build wrapper? Because if you’re using the build wrapper, only the code that’s built is analyzed. So perhaps the change to task.cpp included it into the (non-full?) build where it hadn’t been before. And it, in turn, included task.h, which hadn’t previously been included.
Thank you for this great suggestion. We are using the build wrapper, and every build is a “clean” build (the build wrapper requires this). task.h has been included in task.cpp for many years, so it’s not the case that the change included it in a build where it was not included before. The compilation database is a new idea to me, so thank you, I learned something new researching your suggestion.
Thank you for your suggestions. I checked each of these.
the configuration of the new code period
It is set at 30 days and has not been modified recently.
the evolution of the quality profile applied to your project
We have not changed the quality profile recently. I tried and failed to figure out if SonarCloud has been updated recently. If you have any pointers to this information I will follow them.
the source exclusion/inclusion parameters which you can consult in the background tasks of the project concerned.
We have not modified the exclusion/inclusion parameters recently. That doesn’t seem to be the cause.
Could you give us a screenshot of the issue or the snippet of code where it’s raised? Rules get smarter all the time, so it’s a possibility that that’s why you’re suddenly seeing this as a new issue.
And by the way, is the code marked as new (blue highlight) or only the issue?
@ganncamp thank you for your continued support. I regret that I have limited screenshots to share as the team fixed the issue, and now it has been moved to the “fixed” category.
Here’s a screenshot I took at the time, but it probably isn’t showing what you’re looking for.
Rules get smarter all the time, so it’s a possibility that that’s why you’re suddenly seeing this as a new issue.
I might add, the error is completely correct and legitimate, the code does have the problem, so it’s not a false positive the only thing wrong here is that it shows up as “new”, and the team is convinced (right or wrong) that this happens at least a few times per quarter.
Is there any way to tell if there was a rule update on SonarCloud in the past week? I would be very happy if we could chalk it up to that.
And by the way, is the code marked as new (blue highlight) or only the issue?
I can’t share a screenshot unfortunately for the reason I mentioned already, but I’m pretty certain the code lines were not marked as new with the blue highlight.
When I checked Jira, the last update to the rule was from May, so there weren’t rule changes in the last week. I asked anyway because not everyone analyzes regularly.
What we have been getting better with recently is parsing. Do you still have job logs around from before the issue was raised? Parsing errors would show up there & if they’re not still showing up in recent logs, that would be a good explanation.
@ganncamp I have console output from the builds, but not sonarqube log files exactly. If it might be helpful, I can collect them for future builds? This is raised by my team every so often, so I could come back to this thread with log files next time it comes up.
Yes, the stdout logs of the analysis job are what I was asking about and they’re a standard request when there’s a question about analysis (how it runs, what it found, &etc.). So it would be useful in general to have them available.
@ganncamp I downloaded the full logs, and I can share them with you privately if that’s possible. I searched for the text “ERROR: Failed to parse” (and variants thereof), and neither the last successful build nor the first quality-gate-failed build has any parsing errors.
I did come across a warning in SonarQube that I haven’t actioned yet (cited below), it’s possible that I’m doing something “an old way” and that I need to update my analysis to resolve the issue.
Property ‘sonar.cfamily.build-wrapper-output’ is deprecated; build-wrapper now generates a compilation database. Please use the property ‘sonar.cfamily.compile-commands’ instead to specify the path of the ‘compile_commands.json’ file generated inside the build-wrapper output directory. Visit the documentation for more up-to-date information on analysis using build-wrapper Overview
Hi @boinst,
Do you have this message “SCM publisher is disabled” in the log ?
You can try to force the reload SCM data (ie commit date) with this parameter sonar.scm.forceReloadAll=true
Thank you for the thought @Bachri_Abdel but no, no such message.
Looking for the one you suggested, I found this instead, so I’ll go ahead and set projectBaseDir and see if that does anything useful.
[11:57:30] : [Step 2/2] WARN: Incremental PR analysis: Could not determine common base path, cache will not be computed. Consider setting ‘sonar.projectBaseDir’ property.
That warning you found does need an analysis update, but wouldn’t be related to this question.
Since the old-new issue has already been resolved, that makes further investigation difficult, as you noted. I propose we let this lie until / unless it happens again.
