Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a sonar processor #54

Merged
merged 11 commits into from Dec 29, 2014
Merged

Implement a sonar processor #54

merged 11 commits into from Dec 29, 2014

Conversation

dopuskh3
Copy link
Contributor

@dopuskh3 dopuskh3 commented Dec 5, 2014

Hi,

We've implemented a way for sputnik to run Sonar-runner to report issues.
We use it in conjunction with sonar-ndepend (https://github.com/criteo/sonar-ndepend) but should work with
all sonar plugins as long as they provides the line information.

Cheers

@pjagielski
Copy link
Collaborator

Hi,

Great work!

So it's just running sonar-runner from the cli, no sonar server needed?

public class SonarProcessorTest {

@Test
public void testFilterResults() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename test names in "should<do_something>When<something_happens>" manner, as in rest of the project.

@pjagielski
Copy link
Collaborator

Can you resolve conflicts with master?

@dopuskh3
Copy link
Contributor Author

dopuskh3 commented Dec 8, 2014

Hi,

You need a sonar server to run this processor. Sonar runner pull its configuration and dependencies from the sonar server. It also pulls issues already indexed and only report the new ones to sputnik. That way sonar runnuer instance run by sputnik only reports issues that where added in the review diff - considering your run sonar running after each commit.
Note the sonar runner launched by sputhnik do not index issues on the sonar server (sonar incremental mode).

Rebased on master, fixed the naming and TestEnvironment comments.

F.

@SpOOnman
Copy link
Collaborator

SpOOnman commented Dec 9, 2014

Hi!

Thank you for your submission, but I'm not sure if this is a good change. I have a few concerns about it.

First, this processor requires 3rd party server to run. That's an additional integration dependency that increases complecity of a simple Sputnik.

Second, running Sonar runner, that runs its own analysis (including PMD, FindBugs, Checkstyle and Squid) is redundant to Sputnik.

I am not sure about third. Does running Sonar runner slow down Sputnik? My goal is to run Sputnik and all analysis in less than 30 seconds, even for 100 files.

My last concern is emotional. I wrote Sputnik to get rid of Sonar. These are two tools for different purposes. Sonar is a long run project analysis that should be used for tracking progress. Sputnik is a fast static code analyser intended to support code reviewers. With this PR Sonar is getting to Sputnik and I'm spectical about it.

@damianszczepanik
Copy link
Contributor

I also think this would be useful:

  • main goal of using Sonar is that (correct me if I'm wrong) you don't get error that are marked as false positive
  • if you don't like it you still can switch it off and it will work as it used to
  • If you already have Sonar installed you need to export rules and configuration and maintain them separately (in case rules are changed or upgraded)
  • I was able to run Sonar for more than 100 files in less than 30secs via Eclipse plugin so Sputnik should not run longer. Anyway as long as Sputnik runs faster than maven compile test then I guess its worth to think about it

I'm looking for the release with this support!

@dopuskh3
Copy link
Contributor Author

Hi,

Although it requires additional dependencies note that:

  • enabling sonar is not mandatory.
  • it is really usefull for organizations (like us) that are running sonar and gerrit and are willing to make a faster feedback on code quality than just induce developers to have a look on sonar regularily (isn't that the reason why you created sputnik ?)
  • defining and maintaining rules is a real pain. Having to duplicate this in both sputnik and sonar is even more painful.
  • this plugin do not comment already indexed issues. That mean that you only get comment on added issues on modified lines which is pretty cool.

Regarding the running time, I don't think the sonar feedback take too much time to run (at least in incremental mode) and:

  • why would you make code reviews with 100 files ? I think that's a very bad practice to create such huge code reviews.
  • sonar overhead is really negligible at least when the first run happened (sonar caches needed plugins jars on first run)

Over all this plugin allows to take advandate of the whole sonar plugin library which is really huge (http://docs.codehaus.org/display/SONAR/Plugin+Library).

@cupcicm
Copy link
Contributor

cupcicm commented Dec 11, 2014

I agree that the fact you get all sonar plugins for free with this merge request is compelling.
Also, as noted by @damianszczepanik not having to duplicate your configuration between sputnik and sonar is a good thing IMO.
Although I agree with you, @SpOOnman, that it seems sputnik was not intended to do this (since it makes the findbug / pmd processor kind of redundant.
Could we have more info on why you wanted to remove sonar ? I feel that there are two parts to code analysis :

  • the dashboard part, where you try to get less and less warnings in your code. For this, sonar is awesome
  • the review part, where you don't want to add more. For this, sputnik is awesome.

Now I already have all my configuration in sonar, why wouldn't I want sputnik to run a trimmed-down (incremental) version of sonar to give me the warnings ?

@@ -40,6 +40,9 @@ dependencies {
compile 'ch.qos.logback:logback-classic:1.0.13'
compile 'org.projectlombok:lombok:1.12.6'
compile 'commons-cli:commons-cli:1.2'
compile 'org.codehaus.sonar.runner:sonar-runner-api:2.4'
compile 'org.codehaus.sonar-plugins:sonar-issues-report-plugin:1.3'
compile 'org.json:json:20140107'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this Sonar dependency? We already use Jackson's ObjectMapper to handle JSON. Is this suitable for you to use Jackson instead of a second JSON dependency?

@SpOOnman
Copy link
Collaborator

Sorry for waiting so long.

I still have personal issues with this change, however I've found it useful. Some users want to use Sputnik in a way I didn't think of at first. Even more - in a way that I dropped. But that's fine so I want this PR to be merged.

I've commented inline some details. This PR has high quality, thank you.

Change-Id: Iaf9b4565e8ac2237d5a4d70627487e6bbb4b86fc
Add a few configuration option for further sonar review.

Change-Id: I82b92e291791e838b18b6c9281225ba44161cceb
}

@Test(expected=IOException.class)
public void shouldRaiseWhenNoSonarFiles() throws IOException {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Raise to throw

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@SpOOnman
Copy link
Collaborator

I've found one raise, besides that it is ready to be submitted.

Francois Visconte and others added 9 commits December 23, 2014 16:53
Load sonar configuration specified in sputnik configuration file, build
a valid sonar configuration and run sonar runner inside the same process
running sputnik.

This is not fully functional as we need to parse sonar issues in order
to report them to sputnik.

Change-Id: I6117d97541b65a8c575cd178c948632ed7fe76fc
SonarResultParser parses json result and produces a ReviewResult.

Change-Id: I11e2fc20567570343b20648f8d7ae8bc04d5940b
Change-Id: I86633f86858efbe9aaea177d68492c1ff937273e
Add test fixtures that test sonar will only report new issues

Change-Id: I47dd6d4c088620bd5120a07a155e75ba0687b808
Some sonar plugin do no include git path as the source file path (for
example, sonar-visual-studio plugin generates filenames that are
relative to the module csproj file).

Using the file basename and a recursive match allows Sonar to match
modified files with their indexed names in Sonar.

Although this can generate useless analysis (as some files that are not
included in a review may be analysed), this has a limited additional
cost considering that few files have the same basename inside a
repository.

Change-Id: Ib74289e201098d15c618791f47b2dd657c3a1744
Add sonar as a tool for sputnik in the readme title

Change-Id: I53df772174a7b0478a992dc8a45c1cf844c8958b
As this configuration directive holds multiple configuration file paths
it has been renamed configurationFiles.

Change-Id: I33c4e37a8ac25a81868086a9bdd7d2c62685d517
Rename test and use TestEnvironment class as a base class for test
in order to use helper methods.

Change-Id: I413e2b5d536201dc59059b1fdc0a0c2c1073cc67
Add the rule name so the user can access the description of this
rule to fix the issue

Change-Id: Icff9bdde4e520f1b6e09925ea6e03d0cd6a718ef
SpOOnman added a commit that referenced this pull request Dec 29, 2014
Implement a sonar processor
@SpOOnman SpOOnman merged commit 09cce06 into TouK:master Dec 29, 2014
@SpOOnman
Copy link
Collaborator

Thank you! Spread a word about your use cases with Sputnik :)

rufuslevi pushed a commit to rufuslevi/sputnik that referenced this pull request Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants