Replacement for local issue reports removed by [SONAR-7245] Remove issues report (html/console) feature

[markus....@googlemail.com]

Hi,

we used the issues report plugin to quickly get a report about new issues without having to commit using maven like this:

mvn clean verify sonar:sonar -Dsonar.analysis.mode=preview -Dsonar.issuesReport.html.enable=true

Now, we updated to 6.6 and see that this feature was removed. Is there any alternative? 

We tried SonarLint for eclipse, but it had never the same results as the sonarqube server. So this is not an option for us.

The preview mode with html report always gave us the same results (at least for our setup). 

We used the local preview for a developer to check if his code has violations at an early stage on his branch. After his commit

we also had a jenkins job running using the preview mode to validate the committed branch again in case the developer forgot

to check first. If the the branch has no issues, then we would merge it into the master after code review and our conintious delivery

build starts. This build runs sonar without preview and should produce a ready to ship artifact with no issues.

Now, if no preview checks are available, the conintious delivery build might fail with new sonar issues and that is too late for us.

So we are looking for a replacement on how to check local code for new issues.

Regards,

Markus

[Julien HENRY]

Hi Markus :)

On developer side, all our efforts are focused on SonarLint. I would really like to know with more details what are the (negative) differences you see compared to the old preview mode. Are you relying on some third party analyzers (PMD/Checkstyle/Findbugs)?

On build pipeline side, we have just released SonarQube 6.7, that provides branch analysis support starting from the Developer Edition. This is more powerful than using scanner side preview analysis, since results are really pushed to SonarQube, with the ability for the dev team to manage issues if needed (mark as Won't Fix/False Positive, comment, change severity, ...). Then you can use webhooks and/or web services to decide if the branch can be merged.

Regards,

Julien

[markus....@googlemail.com]

I can't remember the exact details, but we experienced that some issues did not occur in SonarLint (for JavaScript we use the Profile "Sonar way Recommended"), that is why we still got issues in later build steps when sonar was executed on server.

Branch analysis sounds good, but unfortunatelly there will be no budget for the developer edition.

[markus....@googlemail.com]

Now I found at least one issue that prevents us from using sonar lint. We have some "sonar.exclusions" in our maven pom and also some "sonar.issue.ignore.block"s that are not respected by sonarlint. I event tries to set the block on serverside, but didnt help. So we are shown a lot of issues by sonarlint that are actually none.

Am Mittwoch, 8. November 2017 16:49:23 UTC+1 schrieb Julien HENRY:

[Julien HENRY]

Hi Markus,

Settings sonar.exclusions on server side should allow SonarLint to pick it. We will start very soon a sprint to allow configuration of exclusions locally in SonarLint: https://jira.sonarsource.com/browse/MMF-801

Regarding sonar.issue.ignore.block the limitation is tracked in https://jira.sonarsource.com/browse/MMF-850. Would you mind giving us an example of why you are using it, it would help to decide how important it is for SonarLint.

Thanks,

Julien Henry | SonarSource

Developer

https://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/0Kz1SMGwN5o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/a5d2db5b-8e0e-4f84-ada3-5a34360f2b3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[markus....@googlemail.com]

Ok, didnt test sonar.exclusions on serverside, just the issues block.

The use the code ignore block, becase we are developing a JS app extension based on another JS app. Sometimes it is needed, to copy code from the original app to fix bugs or because there is no other was to change the behavior to our needs. Now, if we copy that code, we mark it with a sonar block start and end identifier to prevent sonar analyzing copied code.

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.

[Julien HENRY]

OK, so that's precisely why we don't like block exclusions (or //NOSONAR BTW). It was implemented long time ago, when the ability to flag issues as won't fix was not supported.

You copy code, fine. Aren't you interested to fix bugs in it? You might decide to not fix minor issues, that's you're decision. Then simply mark issues as won't fix. 

Time will pass, the SonarJS analyzer will be improved and be able to report new advanced bugs based on dataflow analysis. With a blind block exclusion, or even with //NOSONAR you'll loose the chance to see these new issues reported.

Julien Henry | SonarSource

Developer

https://sonarsource.com

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4d106f3c-a54a-4a27-a3fd-1790d1fc4a21%40googlegroups.com.

[markus....@googlemail.com]

Actually we are not interested on changing any line of code in the copied block, because with every update we need to check the new version for differences. If we change code there, this makes it impossible to compare. It is not that these are just a few bugs, there are over 200 of them and constantly increaing with each copied block (which we only do if no other option is left). And marking those as wont fix is a bad option as we constantly try to remove wont fixes and the we cannot see what wontfix is our code, which we like to fix/remove, or if it is copied code. So we always have to go through all of them, right?

[markus....@googlemail.com]

Maybe we can use wontfix and custom tags to decide what to resolve later?

[Julien HENRY]

I don't really understand what you mean by "we constantly try to remove wont fixes". Won't fix means... you don't intend to fix the issue. If the issue is not critical to you, and you consider that it can be fixed later, then the correct way to handle that is to "confirm" it (possibly decreasing severity/changing type from bug to code smell).

Still, copying code that contains more than 200 bugs, and not fixing them looks really strange to me.

Julien Henry | SonarSource

Developer

https://sonarsource.com

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8206e0b4-daae-43d1-945c-6aa73051fd3a%40googlegroups.com.

[markus....@googlemail.com]

Ok, so may be we are using wont fixes wrong, we will look into it. The 200+ bugs in the custom code are mainly stuff like complexity or in JS they use „==„ instead of „===„, for example.