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).
Related
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
We'd like to have code analysis results from SonarQube in Stash pull requests, more precisely only for the changed/added code.
The setup looks like this:
Atlassian Bitbucket v4.14.4
Jenkins ver. 2.69
SonarQube Version 6.4 (with sonar-stash plugin from https://github.com/AmadeusITGroup/sonar-stash)
Jenkins fetches changes in branches and builds them. Depending on the branch it will then (for the development branch) call SonarQube to (per default) publish its analysis. For pull requests we want a preview, so SonarQube is called with the parameter -Dsonar.analysis.mode=preview. Additional parameters for the sonar-stash plugin are working so that the analysis result is sent to Stash (Bitbucket) from SonarQube. The problem is, that the results contain all issues/bugs/violations based on the complete source code, not on the changes.
Narrowed this issue down to a problem that the sonar-stash plugin uses a list of issues which are filtered to contain only those issues that are new and linked to a file. So it looks like all issues are marked as new which is strange because in SonarQube we have a baseline for our known (legacy) issues.
Thanks for your time and feedback!
I had a pretty similar issue, my resolution is outlined in the answers below.
My SonarQube Pull Request Issues only question
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.
I am thinking about a deployment pipeline using SVN, Jenkins and Maven. At the moment I'm stuck at the point where I usually would call mvn release:perform on a working copy.
When thinking in deployment pipelines, I want to create a pipeline where every commit could be used to release a software to test/production. Let's say I have 5 builds, and I decide to release build 3 (with revision 3) to production. There will already be 2 new commits to trunk (which is now at revision 5).
Is it possible to use the maven-release-plugin to checkout/build/tag/commit a release at revision 3? When the maven-release-plugin finishes the release it usually commits the modified POMs to trunk.
I'm happy about any kind of information or advice here, so feel free to point me to books (like http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912), blog posts, Jenkins documentation... Maybe I'm completely on the wrong track.
By default, the release plugin creates the release based on the contents of your working copy, it just ensures that you don't have any uncommitted content before doing so. AFAIK it doesn't force an update of the sources, as that's usually the job of the Continuous Integration system (Jenkins in your case). So whatever is checked out by Jenkins will be released.
What you're trying to do sounds more like a configuration change on the Jenkins side, pointing it to the right revision.
On the other hand, if the POM files are modified as part of the release, but have been changed in SVN in the meantime, you will run into a conflict when Maven wants to check in the modified POM files. That's a situation that might happen, depending on how for back you want to go with the release.
Based on this, it might make more sense to always create a branch before doing a release. So you would create a branch based on revision 3 and then create your release in that branch. This way, you wouldn't run into issues with committing resources that have changed in more recent revisions.
Creating the branch and checking it out could probably be automated through Jenkins and Maven as well.
As far as I tested it, it is not possible.
More explicitely, as nwinler said, when you release, maven try to commit the modified pom. But, if it's an older revision than the current one, SVN will complain that your sources are not up to date. So it won't work. ... as far as I know.
You may read docs about promotion build. I don't find any one clear enough to be pointed out (in th few minutes of the writing of this message).