I'm trying to create method without add comment or documentation it, I expected SonarLint would show errors based on rules, but I don't see any errors or warnings. Why?
The particular rules you're looking for are "common" rules applied at the server. You're not going to see them in SonarLint. But in general:
Out of the box, SonarLint runs with the Sonar way (default) profile. If you want additional rules applied in the IDE, you'll need to:
set up a SonarQube instance (assuming you don't already have one)
configure a Quality Profile to your liking
apply it to your project
connect your project in the IDE to the project on the server
At this point you will see (almost) all the same issues in both places.
Related
I'm working on the project, where the developers are trying to write understandable code, so there is no sense to use comments in a lot of places. We have a SonarQube, which is used in other projects and we cannot configure it. All we can do is configuring Sonar in our project's POM file. SonarQube is complaining, that there are not comments in our code with the rule "common-java:InsufficientCommentDensity". I know, that we can ignore some rules using sonar.issue.ignore.multicriteria properties like
<sonar.issue.ignore.multicriteria>junit.assertions.include.messages</sonar.issue.ignore.multicriteria>
<sonar.issue.ignore.multicriteria.junit.assertions.include.messages.ruleKey>squid:S2698</sonar.issue.ignore.multicriteria.junit.assertions.include.messages.ruleKey>
<sonar.issue.ignore.multicriteria.junit.assertions.include.messages.resourceKey>**/*.java</sonar.issue.ignore.multicriteria.junit.assertions.include.messages.resourceKey>
but it's not working with "common-java:InsufficientCommentDensity" rule. Why? And is there a way to ignore this rule in our case?
SonarQube version is 6.7 (build 33306)
Sonar Maven Plugin version is 3.4.0.905
I tested this quite a lot and finally found that setting common rules (anything that starts with "common-xxxx") from scanner side (pom, command line etc) will be ignored and wont work. The language specific rules can be passed as command line arguments and thats why the "squid:S2698" rule is getting ignored correctly. Here is the issue link on the SonarQube JIRA board and it says that it "wont be fixed".
https://jira.sonarsource.com/browse/SONAR-8230
The only option for you is to set the issue exclusion from UI. Here are the steps to set it from U.
If this is a common rule that you want to ignore, then make sure you have admin rights to your project. On the project Dashboard you should see the administration tab:
Click on Administration → General Settings
Click on Analysis Scope on the left hand side
Now set the below property:
Save and run the scan again.
I am generating sonar report from teamcity sonar runner but I see that Quality Profile is set to
Use 'Sonar way' (XML) but I want it to be Stop using sonar way (xml).
Can anyone suggest the parameter or setting I need to do.
Note: I can not share the logs or screenshots here because of organization policy.
The way to handle this is to use the UI to assign the project to the profile(s) you want it to use: Project-level Administration > Quality Profiles. You'll be presented there with an option to assign a profile for each language available in the instance.
If you simply must do this from TeamCity, then use web services to assign the profile. Although once assigned, assignments "stick" so this really is something you should be able to do from the GUI and then just leave alone.
I used parameter sonar.Language=cs. it excluded xml analysis and now I see Stop using sonar way (xml).
https://docs.sonarqube.org/display/SONAR/Analysis+Parameters
sonar.language
Set the language of the source code to analyze. Browse the Plugin
Library page to get the list of all available languages. If not set, a
multi-language analysis will be triggered.
I have read all of the threads about SonarLint not being in synch with SonarQube, but it's just not clicking.
I created a simple Maven project to test SonarLint & SonarQube. I added the sonar-maven-plugin to the project and then ran mvn sonar:sonar.
The project was uploaded to SonarQube. When I looked in SonarQube, I see that it shows squid:S2699 (junit test doesn't have an assertion) as a blocker.
However, in eclipse, there is no such issue shown by SonarLint.
I purposely chose this one as it's not a PMD/FindBugs/Checkstyle issue.
I have verified that squid:S2699 is active on the server. Obviously it is, because SonarQube displayed it.
There is only 1 Quality Profile: SonarWay.
Edit: I am in connected mode.
Does anyone have any idea why?
I am using:
Eclipse Neon.3 Release (4.6.3)
sonar-maven-plugin 3.0.2
maven 3.3.9 (the one embedded in eclipse)
SonarLint 3.2.0.201706271328
SonarQube 6.3 (build 19869)
Here are the screenshots as proof.
It seems your test file is not treated as a test file, but as a source file. I say this based on the kind of errors that are reported (remove unused variable) and the kind of errors that are not reported (no assertions).
As you might know, different rules are applied to sources and tests.
SonarLint decides whether a file is a test file or not based on the Test file regular expressions preference, which you can find in Window / Preferences / SonarLint. The default value is **/*Test.*,**/test/**/*,
this seems to work well in a wide range of cases, and looking at your screenshot, it should work for yours too.
So first of all verify this setting.
If the value is different from the default,
I suggest to change it back to the default as a sanity check.
Then you can tweak the value according to your needs.
It's also good to verify that my theory is correct about SonarLint treating the file as test instead of source, by inspecting the SonarLint Console:
In the Console view, click on the Open Console dropdown, select SonarLint Console
In the Configure logs dropdown enable Verbose output
Trigger an analysis of the test file (make a change and save the file)
You should see output like this:
[
baseDir: ...
workDir: ...
extraProperties: ...
inputFiles: [
/path/to/your/test/SonarProofTest.java [test]
]
]
The [test] at the end of the filename indicates the file is treated as a test file. If it's not there, then the file is treated as a source file.
I want to use a specific sonar profile with analysis mode preview for generating comments that go into our github pull requests.
The default quality profile for the project includes minor and info level rules which will cause hundreds of extra comments (and literally thousands of github notification emails). So it has to be a quality profile specific to this purpose.
Running the build like this:
mvn sonar:sonar -Dsonar.profile.java=PRComments -Dsonar.analysis.mode=preview
Fails with the following error:
sonar.profile was set to 'PRComments' but didn't match any profile for any language.
The PRComments quality profile exists and works perfectly if I don't specify the preview mode. And yes I know that -Dsonar.profile is deprecated and it makes me sad too.
For info I'm using the sonarqube github plugin http://docs.sonarqube.org/display/PLUG/GitHub+Plugin to push the comments into github - but the failure above appears even if I don't use this plugin. Unfortunately the github plugin doesn't seem to have an option to skip adding comments for violations below a configurable severity level.
Is this possible or do I have to give up?
According to the documentation I've found Sonar will not analyse test code by default. I found some Jira's that indicate it should be possible but nothing with enough information on how to do it.
It's java code setting under src/test/java. I use both the eclipse plugin for local analysis and sonar-runner plugin for gradle via a jenkins job on the CI server so ideally the solution would support both those.
Ta,
Andrew
As of SonarQube 4.2, the only way to have some test code analyzed is to activate rules from "PMD Unit Tests" repository inside your quality profile.
Note that these are rules specific to test code (like the existence of at least one assertion). You can't activate "standard" rules on test code yet. You can vote for the following ticket to extend the scope of source analysis: SONAR-3748