Using SonarQube 5.6.6 to scan source not managed with a SCM (like GIT or SVN).
But with our "in-house" tool, we know who made the last changes (similarly than the last committer in Git or SVN).
is it possible; in sonar properties file used to make the analysis; to give the developer name (same than into Sonar) that change the source to have new issue automatically assigned ?
I did find the information here :https://docs.sonarqube.org/display/SONAR/Analysis+Parameters.
You cannot do this by specifying any parameters. You have to create your own SCM provider and next add a parameter to SonarScanner:
-Dsonar.scm.provider=custom-id
Related
I configured a project in SONAR(6.1) to run from jenkins and configured to use clearcase as scm.
sonar.scm.provider=clearcase
And our clearcase is configured to use Local and Tst Streams.
Now when i checkout and checkin any changes into Local Stream for the first time it creates new branch for the changes .
When i checked the clearcase annotate(BLAME) information, its showing up correctly. But in SONAR it is showing incorrect.
Here is the information from annotate
0 sgadey01 \main\FW_3.0.0.0_TST\FW_3.1.2.0_TST\FW_3.1.2.0_LOCAL\1 | | System.out.println("testing");
and information from SONAR as in the below link with user bdiaz.
https://s28.postimg.org/8m8l921rh/sonarerror.png
Is there any known limitation with sonar? for cvs plugin they mentioned revision has to be passed manually in limitations(https://github.com/SonarSource/sonar-scm-cvs).
Thanks
sandy
The SonarQube ClearCase SCM Provider is simply running cleartool annotate from command line and parsing output (see https://github.com/SonarQubeCommunity/sonar-scm-clearcase/blob/master/src/main/java/org/sonar/plugins/scm/clearcase/ClearCaseBlameCommand.java) so I'm really surprised you get different results.
You can try to restart analysis and force the SonarQube scanner to collect blame again (there is a cache to not compute blame on files were content was not changed compared to previous analysis):
sonar-scanner -Dsonar.scm.forceReloadAll=true
I have set up my TeamCity 10.0.3 to create an assembly version number during the project build that uses the build.vcs.number (which corresponds to the changset number on the VCS Root - taken from Plastic SCM) as one of the parts.
The format is similar to this; {major}.{Minor}.{build.vcs.number}.{build counter}
This method has worked perfectly for quite some time returning the changset number (and only the number) from my VCS system.
The Plastic plugin for TeamCity has now been upgraded to the latest version (SNAPSHOT-201611231807) and since the upgrade after the VCS Root has been created the build will successfully return the changeset number that can be used within the assembly version number.
The error occurs as soon as anyone checks something into the monitored branch - at this point if an automatic or manual build is triggered the information returned as build.vcs.number has lots of additional information that breaks the build.
An example of what is returned after a checkin is:
cs.418 (guid:6a2d5c45-b1b8-4f03-889c-3f3c80c6e209)
This appears to be both the changeset number along with the ID of the changset.
If I re-create the VCS root from scratch the correct number will be returned - until something is checked back in.
How can I resolve this error as all I want returned is the changset number
many thanks in advance
We have just released a new Teamcity plugin version including new features and a big code refactor. We are aware of this problem and we are going to configure the "build.vcs.number" variable to always show the changeset number (as we do in previous versions of the plugin). The task should be done very soon.
Please contact us at support at codicesoftware dot com if you need more information.
We tried to examine jenkins svnmerge plugin what it can do for us to minimize efforts for automatic branching from SVN. So we checked the option "Accept Integration from Subversion feature branches" and created a new branch. This runs very easy and fine but there are a few drawbacks, we could not resolve yet:
jenkins does branching from trunk. Is it also possible to create a branch from a freshly created tag?
the new branch does not contain the incremented version number in the pom.xml. Can this be done by additional configuration?
the new branch does not contain the updated scm-connection-tag (/trunk to /branches) in the pom.xml. Can this be done by additional configuration?
I use my own branching strategy with "Execute Batch/Shell" step and command line SVN.
I use my own ant script to go through the pom.xml and replace the version number via regex.
Use JobCopy Builder when using your own branching strategy, have a "template" job, and copy from it with JobCopy and modify parameters as needed.
I am currently trying SCM blame feature in latest (5.1.2) SonarQube. My problem is that retrieved blame shows only latest commit for entire file. This mean that one user is responsible for entire file. According to documentation it should be possible to have SCM info line-based - Each line with commit ID, Date and user.
We are using Perforce for SCM.
In TeamCity, it is set as maven build step with flowing parameters:
-Dsonar.jdbc.url=%system.sonar.staging.jdbc.url%
-Dsonar.jdbc.driverClassName=net.sourceforge.jtds.jdbc.Driver
-Dsonar.jdbc.dialect=postgresql
-Dsonar.jdbc.username=%system.sonar.staging.jdbc.username%
-Dsonar.jdbc.password=%system.sonar.staging.jdbc.password%
-Dsonar.host.url=%system.sonar.staging.host.url%
-Dsonar.scm.forceReloadAll=true
-Dsonar.perforce.port=%vcsroot.port%
-Dsonar.perforce.username=%vcsroot.user%
-Dsonar.perforce.password.secured=%vcsroot.user%
-Dsonar.scm.provider=perforce
-Dsonar.perforce.clientName=%env.P4Workaround%
-Dmaven.scm.perforce.clientspec.name=%env.P4Workaround%d%
Do I need to adjust something or this might be bug in SonarQube?
What is the version of SonarQube Perforce plugin you are using. This issue should have been fixed in version 1.2. But you may have to analyze project from scratch to see the changes (delete project in UI then do a new analysis).
I recently started using SonarQube on my Maven Java Project. The problem is that I modified a single line in a Class which causes Sonar failing to load the project into the database. Why does Sonar know that my project is checked into a SVN and why does mvn sonar:sonar fails with "can not blame XXX on line YYY" if a class is not committed into the SVN?
I am the only one working on this and I dont want to check in every single change or experimental code snipet. How can I turn this feature off?
Thank you!
SCM integration (which detects that your projects uses SVN) allows SonarQube to track changes to source code, e.g to compute coverage on new code, new issues etc.
A standard analysis is supposed to be performed from commited code (e.g by a continuous integration server) to serve as a reference.
In your case, I would advise you to use the incremental mode: this will allow you to perform an analysis on your local code changes, which will not be persisted to the central server, but which will show you which issues your new code introduced/fixed (this is the analysis mode used by the IDE integration plugins).