I following the official support of sonarqub http://docs.sonarqube.org/display/SONAR/SCM+support
and I got the error at above.
did I miss something need to config, or configure wrong
08:46:33.723 INFO - Sensor SCM Sensor...
08:46:33.897 INFO - SCM provider for this project is: git
08:46:33.898 INFO - Retrieve SCM blame information...
08:46:33.915 INFO - 632 files to be analyzed
08:46:34.377 INFO - Author: PersonIdent[Not Committed Yet, , Tue Feb 3 08:46:34 2015 +0000]
08:46:34.379 INFO - Source commit: null
08:46:34.377 INFO - Author: PersonIdent[Not Committed Yet, , Tue Feb 3 08:46:34 2015 +0000]
08:46:34.924 INFO - Source commit: null
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 1:01.699s
08:46:35.891 INFO - Author: PersonIdent[Not Committed Yet, , Tue Feb 3 08:46:35 2015 +0000]
08:46:34.930 INFO - Author: PersonIdent[Not Committed Yet, , Tue Feb 3 08:46:34 2015 +0000]
08:46:35.930 INFO - Source commit: null
Final Memory: 27M/318M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Unable to blame file
thanks very much.
scm. provider=git . A full clone is required for this integration to be able to collect the required blame information (see Known Issues). If a shallow clone is detected, a warning will be logged and no attempt will be made to retrieve blame information. Git integration uses JGit.
There's a setting at global and project levels to disable the SCM sensor. It's off by default. Look under Administration > SCM > Disable the SCM Sensor.
The property to be declared to tell SonarQube which SCM plugin should be used to grab SCM data on the project is sonar.
This is because when running an analysis, SonarQube expects that all files should be committed.
Indeed, SonarQube assumes that when you run a standard analysis (that pushes data to the server), there should not be any uncommitted changes on a single file of the project, because this would potentially push information that won't be relevant with the real source code on the repository. That's why the analysis will fail.
This is obviously not the case when you run a preview analysis: as this kind of analysis does not push data to the server and only reports issues locally, then it's not a problem to have uncommitted changes and the analysis will therefore not fail.
I've updated the documentation to make this clearer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With