We launched sonar 4.5.4 in one of our application. Then, we have upgraded sonar with 6.7.5 version and we have got different results.
e.g.: the rule DLS_DEAD_LOCAL_STORE. When we passed our code with 4.5.4 version, this critical rule was not broken at all. With the new version, it appears as a new critical bug even when no changes have been implemented (last commit for this classes was made more than one year ago).
Is there any documentation about rule implementation changes per versions?
Does anyone any experience with this?
When you upgrade SonarQube you have to prepare yourself for some (big) changes. There is a large gap between 4.5.4 and 6.7.5 so, do not be surprised that checkers have been enhanced and severity revised.
It is normal and you should analyze changes before performing any application upgrade.
Related
We were using Sonarqube Enterprise Edition and it’s version is 9.2 and we upgraded it to 9.3 yesterday. So we always use latest version for Enterprise Edition.
I think Sonarqube New Code definition is working wrong. I will try to tell you with our example.
You can see what our project’s New Code definition is.
I think Sonarqube should calculate difference code from the previous version. But it did not do that.
P.S. We scan our repository’s develop branch on Sonarqube every night as scheduled. So the previous version is yesterday’s scan.
We work with feature branches in our repository. Basically, we create new feature branch from develop, then we develop our features in the feature branch. Sometimes it takes one or more weeks. We did a lot of commits in this duration. After we finish developing, we merge the feature branch to develop. And that night, Sonarqube scan develop branch again. I think the merged feature branch’s codes is all new code. But Sonarqube only considers commits made that day(last day). Previous commits’ codes are not shown in New Code reports.
I hope I was able to explain my problem.
Update 1:
I tried to fix the Sonarqube Project’s version nubmer. After that, the New Code definition shows as “Started 5 days ago”. As you can see the below image. It means it takes 5 days period.
But I tried to tell before. I want to see all merged branches, commits to develop in new code report for every day. Is there any other suggestions?
Thanks.
I'm trying to update Sonarqube usage to the latest LTS Community version, which at present is version 6.7.5. Prior to the upgrade I have been using sonarqube 5.4 and the Github plugin, and with these when we make Github pull requests the Sonarqube analysis runs in "preview" scan mode and makes comments on the pull request for any issues the scan finds. This setup is largely following this pattern.
However, with the upgrade to 6.7.5 this same flow is no longer working. The Github plugin
"is deprecated, and its functionality more than replaced by the
Developer Edition."
I understand that the Developer version of Sonarqube has pull request commenting built-in, but I have a strong preference to continue using the Community version due to the cost differences. Essentially, something that was once free and part of the open source version seems to have been removed or broken in the latest free and open source version because a similar paid option now exists. So I am trying to find a way to preserve the previous Community version usage with the latest Community Sonarqube version. 6.7.5 Community version runs the Github plugin (even though it the plugin is deprecated), but so far I have been unable to get things to make comments on the Github pull requests.
Is there a combination of parameters/plugins that will allow my 6.7.5 Community version of Sonarqube to analyze and make comments on a Github pull request?
These may be relevant:
https://community.sonarsource.com/t/after-upgrade-to-sq-6-7-5-target-sonar-issues-report-issues-report-light-html-is-not-produced/1921
https://jira.sonarsource.com/browse/SONAR-9770
https://community.sonarsource.com/t/preview-mode-ignored/1234
I believe in my case the issue was that after upgrading the rule sets changed, so the rules I initially thought were being used with 6.7.5 were not in fact being applied. This gave the impression that Sonarqube was not commenting on the pull request and led to my question. But after enabling the rules appropriately I was able to see it comment on GitHub pull requests as expected. So this appears to be a case of user error!
We have two Environment of Sonar having versions (5.6 & 6.3).
We have set up all the sonar quality profiles,types,rules,severity identical in both environments.
But when we do analysis from both versions on the same repository, we are getting difference in the sonar analysis and its issues severities.
Please help us to find where the issue may persists.
Generally speaking:
only because you have the same version of SonarQube, does not mean that you are using the same Plugins.
Even tough the plugins have the same rules, they are also differ from release to release. Plugin developers find bugs in the rules, or there is a big change of severity, and movement from category "bugs" to "code smell"
so, as long as your server is not running the same plugin versions - you can not compare the outcome of those two!
My project is analysed by SonarQube for every VCS check-in and I have observed some strange behavior:
The dependency cycle-count changes to extremes every now and then.
When viewing the details (e.g. clicking the link) the old (smaller number) value is displayed. What could be the cause of this?
This feature has been dropped from SonarQube platform in version 5.2 thus even if there might be some flaws on this on sonar java analyzer side there is not point to make an effort to fix them as this will be dropped when it will move to LTS version 5.x
See this ticket for detailed explanation : https://jira.sonarsource.com/browse/SONAR-6553
We set a lot of false-positive violations using SonarQube UI.
Can you advise how to keep those false-positive violations during upgrade?
We are trying to upgrade Sonar from 3.5.1 to 4.0 and it seems that the those false-positive violations were removed.
One thing you can do is export the list of false positives so that you will at least know what they are and which files/issues they are attached to. I'm not sure how to then import the list, but in the worst case you can just mark violations as false-positive again, after first checking against the exported list.
The Sonar Rest API query to obtain the list of false positives is as follows. It worked in Sonar 3.2, but I'm not sure if it works in your particular version. It does not work in SonarQube 4.5.4 and possibly other versions, but I don't know.
http://sonar.your-server.com/api/reviews?resource=com.yourpackage.yourcomponent:yourtag&review_type=FALSE-POSITIVE&format=json