A checkstyle-result.xml file is created via maven checkstyle plugin and is imported as part of the maven sonar scanner plugin result.
The graph on the project shows the following information:
115 Issues for the 1st Import (baseline)
180 Issues for the 2nd Import (change)
Expectation:
~65 New Issues
Actual Behaviour:
The result is that only 12 Issues are marked as ‘New Issues’ in the ‘New Code section’, none of them are Checkstyle Issues.
Note:
No additional configuration for checkstyle has been done on the SonarQube. As fas as I understand there is nothing more to do than installing the plugin.
As part of the change for the 2nd scan I have added a completely new file, which contains a number of normal sonar issues (which are correctly displayed as ‘New Issues’) and a number of checkstyle violation (which are only shown in the ‘Overall Code’ Tab as ‘Open Issues’).
Checkstyle Issues are marked as: “Issues detected by an external rule engine: checkstyle”
Question:
Why are checkstyle issues not part of the ‘New Issues’ in ‘New Code’ Tab?
It seems I have misunderstood what the plugin is required for.
My understanding was that the plugin was required to display checkstyle related errors.
However, after the installation I did not really see any way to actually configure something on the serverside. There were no new checkstyle related rules and there is no way to actually import a checkstyle rule configuration into the server.
So I came to the conclusion that I have to upload the checkstyle-result file - via the sonar scanner - from maven.
For now I just removed the plugin from the server and triggered the same process again.
The issue remains the same:
180 issues are in the ‘Overvall Code’ Tab
12 issues are in the ‘New Code’ Tab, none of them are checkstyle related
I am not sure whether I can provide a project by itself.
However I can try to extract (and cleanup) the files that are actually send to the sonar, e.g the sonar result file and the checkstyle result and rules file. Would that be sufficient to reproduce the issue on your side?
I have not been able to build a sample project yet, however I noticed that there the issue seems to be related to the ‘Introduced’-Timestamp of the related Code Smell Issues that are created on side of the sonar qube.
Sometimes the date of the issue is before the date of the baseline creation date which is displayed on the activity timelime.
My current assumption would be that the determination of what is old/new is based on this timestamp - Can you confirm this?
I can’t (always) reproduce this issue yet. There might be some local (or server side) caching involved here. At least I have seen an related issue on sonarqube labeled as ‘1 hour ago’ when I just created the file and submitted the result of the scan to sonar.
SimpleProject.zip (7.1 KB)
I have added a sample project to reproduce the classification issue. (However in this example all issues are determined to be old - not only the checkstyle related issues as mentioned original.)
There is a readme inside the zip which hopefully describes the needed steps and what the two batch scripts (issueing maven commands) are doing.
My conclusion on the issue is, that the problem is that the SonarQube considered the timestamps from git when the file was created/changed and compares that to the ‘New Code’ baseline date from the related SonarQube Project.
A workaround for this issues seems to be to disable the scm for the sonar scan. In this case the timestamps for the issues are linked to the timestamp of the actual scan/analysis result upload to the server.
What you’re describing is issue backdating, and usually regarded as a good thing.
Can you help me understand why, if the issues are from before the baseline was created, you’d like them to appear as New Issues? That would mean that anytime you introduce a new external analyzer, those issues are all raised as new.
Our buildpipeline consists out of Gerrit, Jenkins and SonarQube Server. Based on a code change we create a new sonarqube project and do a scan only on the modified files (There is a separate setup for scanning the whole project, but that takes much longer).
Initially we scan the (git) parent and afterwards we scan the (git) patchset. Based on the workflow there is no guarantee that the parent commit is actually older than the patchset commit - as Gerrit requires rebasing the changes before being merged. (A newly added file that was not touched by the rebase might still have a git timestamp, that is older than the baseline analysis)
Any new external analyzer would be introduced the same way. So the baseline scan would cover all ‘old’ issues, while the new scan would cover all issues. Therefore my definition of ‘new’ is: issues that are not existing in the baseline.
As the documentation describes: “As a consequence, it is possible that backdating will keep newly raised issues out of [new code]”
It sounds like my original issue (sonar scan issues were marked as new, external checkstyles issues not) falls into this category.
Is there a way to only disable the backdating instead of disabling the scm completely?
Turning off the scm causes some Issues when files are renamed - as everything in the file is considered new at this point.
After we have identified the issue being the git timestamp, I opted for modifying that one instead. Now I am running a “git commit --amend --date=now --no-edit” directly before the patchset analysis step. For now that seems to work and backdating seems to be applied correctly.