Usually, issues creation date is the date the faulty line of code was commited. Thanks to this, I have some issues that are 5-6 years old, even though I setup Sonar analysis only a few months ago.
However, I noticed that for some issues, the creation date is computed differently : the creation date of the issue is not the commit date for this date, and I would like to understand why. It so happens that April 29 at 9:35 is the date of the last analysis on that branch.
Sonarqube server is at version 7.9.2.30863.
I made some research and found the following: https://docs.sonarqube.org/latest/user-guide/issues/#header-…. As far I understand this page says that all created issues have a creation date equals to the commit date, except if one of the following conditions is true:
first analysis of a project or branch. More on that below. Let me move the rest out of the way first.
When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated). The quality profile used for this analysis was not modified
When SonarQube has just been upgraded (because rule implementations could be smarter now). I know I did not upgrade the server. However, it is difficult for me to prove that the server was not upgraded by someone else. I checked the logs, and all I can say is that the Sonar Qube server was last restarted a few days before the first ‘faulty’ analysis. Since I believe that an upgrade would force a restart, I can assume this condition I out of the way too.
When the rule is external. I do not know what an external rule is. It seems to be linked to the configuration found under Administration > General Settings > External analyzers. However, it is all empty, so I believe I use no external analyzer, hence no external rules that are checked during an analysis.
Back to the first condition: ‘first analysis of a project or branch.’. This is now the most plausible explanation since all the other conditions are out of the way. Sonar does not provide much history for short-lived branches, so I had to check my continuous integration pipelines to find out when the previous analysis was on that branch. I found a successful execution a few weeks before that (2021-04-09). Since it was more than a few days ago, could it be that the results of that analysis were somehow purged and that the analysis that took place on April 29 was somehow a ‘first analysis’ again? How to check that?
Conclusion: I still do not know why the date on that issue(and some others too) is wrong. All ‘faulty’ issues are located on the same file. I would gladly welcome any help.
First I would like to clarify that your understanding below is wrong. The documentation says that in the below cases the issue is backdated meaning that even if the issue is discovered today, it’s creation date will be as old as its corresponding commit (the general behaviour that you expect and that you like)
The only reasons why an issue would not be backdated (ie dated from its commit are) are listed below:
The SCM integration has been disabled: The sonar.scm.disabled=true property as been set for the project analysis (the default is to NOT disable SCM integration). I doubt this is your case
If that was configured, all issues of that projects would be dated from the analysis date. There should be a scanner INFO log that SCM publisher is disabled
The SCM integration does not work.:The SonarQube scanner does not automatically detects that a particular project comes from a given SCM (there are usually signs, like a .git or a .svn in the project root directory).
If that happens, all issues of that projects would be dated from the analysis date AND you should a have a WARNING log from the scanner that autodetection failed.
You may try to force detection with sonar.scm.provider=<git_or_svn>
For different reasons the SCM data is partial, causing some issues to be properly backdated and some not (the scanner does not find the commits where an issue is).
I suspect that you are in this situation. In that case there’s an option to force reload SCM data sonar.scm.forceReloadAll=true that could hopefully solve your problem.
First of all, sorry for not replying sooner. I was away, and unable to progress on this topic. Many many thanks for taking the time to look into my problem and shed some light on it.
So, I understood it backwards, and indeed I would like all my issues to be backdated, not the other way around. so I tried your solution by adding the -Dsonar.scm.forceReloadAll=true option when invoking maven (I launch my analysises through maven in a continuous integration pipeline). Unfortuntely, it seems that it did not solve my problem, as I still have one error that was not backdated, as can be seen below.
First of all, is this an isolated issue not backdated properly, or you see that for many issues ? for all issues ?
Second, I would need to look at the logs of your full pipeline to find out why you end up with that. Can you attach the zipped logs of you CICD pipeline ?
Can you detail what SCM you use ? Git ? Svn ? Something else ?
Sorry about the screenshot, I don’t know what the problem was. It just showed an issue with creation date != commit date.
I did a search based on creation date, to isolate all errors that are dated from the last analysis (i.e. search from 17/05 to 18/05). I got 17 results, whereas the complete project has 8k+ issues total. So, it seems that my issues are not properly backdated for isolated issues only.
I picked one issue at random from those 17. The impacted file is a pom.xml file. The associated error is “Remove this commented out code.” because some xml is commented out. Checking the file history, the last update on that file was made last October. So it seems that issues not properly backdated are not newly created ones only.
My scm is git. As for the logs, I am quite reluctant to post it publicly, as it might contain sensible information. Can you please provide an email address so I could send the logs to you privately? I did not find a way to send private messages through this forum.
