Hi,
We’ve been using SonarQube Entreprise V8.9.2 for 1 week. Before that, we worked on SonarQube Community Edition V8.4.
We have many java projects analysed by Sonarqube. Sometimes, issues are raised as new ones, but the commits are old and nobody in my team wrote on these lines of code.
Here is a screenshot of the problem
Do you have any idea of the problem ?
Thanks for your help.
Hi,
Were there any warnings in the analysis log about missing SCM data?
Ann
Thanks for your reply.
Our Sonar analyzes run every nigth. Yesterday, 2 issues were reported as news on a java project which has not changed for 5 days.
In the logs, I can see many warnings:
[WARNING] Invalid character encountered in file E:/Applis/Jenkins/workspace/portail-courtage-pipeline/portail-courtage-war/src/main/webapp/media/adminLte/css/style.css at line 6 for encoding UTF-8. Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.
[WARNING] Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
[WARNING] /E:/Applis/Jenkins/workspace/portail-courtage-pipeline/portail-courtage-dao/src/main/java/fr/thelem/portail/courtage/dao/impl/NotificationLuDao.java: Some input files use unchecked or unsafe operations.
[WARNING] /E:/Applis/Jenkins/workspace/portail-courtage-pipeline/portail-courtage-dao/src/main/java/fr/thelem/portail/courtage/dao/impl/NotificationLuDao.java: Recompile with -Xlint:unchecked for details.
[WARNING] /E:/Applis/Jenkins/workspace/portail-courtage-pipeline/portail-courtage-war/src/main/java/fr/thelem/portail/courtage/interceptor/CustomLogInInterceptor.java: Some input files use or override a deprecated API.
[WARNING] /E:/Applis/Jenkins/workspace/portail-courtage-pipeline/portail-courtage-war/src/main/java/fr/thelem/portail/courtage/interceptor/CustomLogInInterceptor.java: Recompile with -Xlint:deprecation for details.
[INFO] SonarQube version: 8.9.2
[INFO] Default locale: "fr_FR", source code encoding: "UTF-8"
[WARNING] SonarScanner will require Java 11 to run, starting in SonarQube 9.x`
I don’t see anything about missing SCM data.
Hi,
Thanks for sharing your warnings.
It might be useful for you to compare the full analysis logs from this analysis versus the previous analysis to see what changed. You’ve got a warning about unresolved imports/types. Was that present in the previous analysis where these issues were not raised?
In general, when you see new issues on old code it’s going to either be because the SCM information was messed up or because something in that code’s environment changed - the surrounding code or perhaps the information available to analysis, maybe the targeted Java version…
Ann
I compared the full analyzes logs and I see nothing…
The difference between these 2 versions is only a maven release.
I see the warning about unresolved imports/types was already present.
We move our java projects on Git last year. Before that, it was SVN.
Hi,
Are those timing differences the only changes in the log?
Ann
Hi,
In the log, yes.
But, I see in Sonar Interface, rules changed between these runs.
I don’t understand why old issues raise as new because of these rules. Only rules “Securty hotspot” was activated.
Hi,
At this point I’m out of guesses. I’ve flagged this thread for more expert attention. It may help if you can provide full before/after analysis logs.
Ann
Hi,
Thanks.
Today I have the same problem but I am showing it to you differently.
On a java project analyzed for over a year, SonarLint reports an issue that SonarQube Server does not display on its interface: “Fields in a” Serializable “class should either be transient or serializable (java: S1948)”
SonarLint is connected to our SonarQube server.
If I commit my project, this issue will raise as new in Sonar even though it is not.
How can you explain that this issue was not detected before?
The rule java: S1948 has already been activated for a long time on the quality profile used.
This point is important for us because we have many projects with a lot of lines of code for many years. We want to separate technical debt from new issues and this problem does not allow us to be effective.
If it helps, we changed the source code management during this year (SVN to GIT)
Thank you for helping us find solutions.
