I recently configured our build server using bamboo and Sonar. In our case we have a multiple developer environment and chose to not only analyse our trunk but also the branch. The nightly builds of trunk and branch are analysed by sonar. And there lies our problem. The last build will be the build saved in Sonar, which is plausible from a Sonar point-of-view, ie the projects have the same name so are probably the same.
In Branch we have fixes for our major release all projects name and code are same just in branch we have bug fixes. so we would love to see the analysis of branch and trunk separately in sonar dashboard.
The question is there is a way to make multiple version of the same project in Sonar? Or is there any other best practice in this situations?
Looking forward to you replies :)
Use the sonar.branch analysis property to distinguish the branches from head and from each other. Note that there are limitations. E.G. Issues marked "False Positive" in one version of the project will not show up as FP's in the other versions.
More analysis params in the docs
We have just started using Sonarqube 5.1 integrated in TFS build as described on this page http://www.sonarqube.org/announcing-sonarqube-integration-with-msbuild-and-team-build/
We have one main branch, and two development branches for the same project.
What is the recommended strategy for handling this?
I want to be able to see analyze result trends over time and also let people working in different branches able to see analyze result for the branch they are working in. As far as I can see the Sonar msbuild runner (https://github.com/SonarSource/sonar-msbuild-runner) only supports projectkey, projectname and version, but not branch key.
Any advice and suggestions will be greatly appreciated!
Indeed Wangen, I do confirm that the MSBuild Runner 0.9 doesn't yet provide a way to inject some SonarQube properties and so including the "sonar.branch" property. This limitation is going to be dropped in version 1.0 of the MSBuild Runner. Nevertheless, you must be aware that the support of branches by SonarQube is really limited because at the end in your case you're going to have 3 different projects in SonarQube and for instance flagging an issue as false-positive won't lead to flag the same issue in another branch as false-positive.
I am upgrading from sonar 3.3.2 to sonarqube 4.5.1. I am comparing one project in each version. Everything looks good except the technical debt and the unit tests.
Why is this happening?
Here is the technical debt in 3.3.2:
Here is the technical debt in 4.5.1:
In the past when I get 0 TD & 0 Issues, it has been because sonar runner did not analyze the appropriate files either because the sonar.language was wrong or the exclusion patterns resulted in a few/no files to analyze. Try drilling down to see which files got analyzed by clicking on issues "0"
I would also check the activated rules to see if the rules that found issues got deactivated. To do this, check the logs for the quality profile sonar runner used then go to Quality Profiles on your sonar site & check that profile to make sure it has activated rules
It is around 10 months now that Jenkins split off from Hudson.
When looking at the project homepages I am wondering what the differences between Hudson and Jenkins in the meantime really are. From the changelog I do not realy learn much. There are a bunch of changes and the major difference seems to be that Jenkins releases more often with less changes and Hudson less frequently, but then with more changes in a release.
Are there any notable differences yet?
So are there things that make me as a developer needing a CI system more productive rather with the one or the other?
Is one of them more stable than the other?
Is there any difference yet that has nothing to do with politics around Oracle?
What is the most notable difference from your point of view?
One notable difference is that a big number of plugins moved to Jenkins. While you would still be able to use the old versions with Hudson, the newer versions depend on Jenkins already. Also new plugins are mostly created with dependencies on quite recent Jenkins versions, so you probably won't be able to use them without hassle on Hudson.
This will probably differ from plugin to plugin, some might be more compatible with Hudson than others, while still others provide versions for both tools. But if something does not work well with a plugin you will receive help easier if you use Jenkins.
EDIT: Here is an interesting link I found, not only providing some solid numbers on the different paths Jenkins and Hudson have taken, but also addressing the (non-)issue of IP that was mentioned in the other post here...
check out the work being done on cleaning up the code and the IP checks that are needed to belong to Eclipse Foundation. This is one of the big differentiators if you care about clean IP.
How many plugins are you using? Hudson supports many of the most important plugins independently and is working with plugin owners to keep compatibility with those that are still maintained by their owners at Jenkins.
See the JavaOne presentations that show how Hudson is being maintained and new features added.
https://oracleus.wingateweb.com/scheduler/eventcatalog/eventCatalogJavaOne.do (search for Hudson)
Also check out the Hudson project at Eclipse http://www.eclipse.org/hudson/
We are working on a web project from scratch and are looking at the following static code analysis tools.
Conventions (Checkstyle)
Bad practices (PMD)
Potential bugs (FindBugs)
The project is built on Maven. Instead of using multiple tools for the purpose, I was looking at a single flexible solution and came across SonarQube.
Is it true that we can achieve the results from Checkstyle, PMD and Findbugs with SonarQube?
Sonar will run CheckStyle, FindBugs and PMD, as well as a few other "plugins" such as Cobertura (code coverage) by default for Java projects. The main added value, however, is that it stores the history in a database. You can then see the trend. Are you improving the code base or are you doing the opposite? Only a tool with memory can tell you that.
You should run Sonar in your CI system so that even things that take some time to execute (such as CPD – copy paste detector) can run. And you'll have your history. Whereas with an Eclipse plugin, for example, you'll detect violations sooner – which is great – but you will be tempted to run it less often if it starts taking too long, or run less "quality plugins" (such as skipping CPD or skipping code coverage analysis). And you won't have history.
Also, Sonar generates visual reports, "Dashboard" style. Which makes it very easy to grasp. With Sonar in Jenkins, you'll be able to show developers and your management the effects of the work that was performed on the quality of the code base over the last few weeks and months.
Sonar uses these 3 tools as plugins and aggregates the data from all three giving addition value by showing graphs and such from these tools. So they are complementary to sonar.
Yes and no. In addition to the other answers.
SonarQube is currently on the way to deprecate PMD, Checkstyle and Findbugs and use their own technology to analyze Java code (called SonarJava). They do it, because they don't want to spend their time fixing, upgrading (or waiting on it) those libraries (e.g. for Java 8), which for example uses outdated libraries.
They also got a new set of plugins for your personal IDE called SonarLint.
Sonar is great, but if you want to use the mentioned tools separately and still have nice graphs, you can use the Analysis Collector Plugin as part of your Jenkins CI build. A slight advantage of this is that you can check in your PMD/Findbugs/Checkstyle configuration into your SCM and have it integrated into your Maven build, rather than relying on a separate Sonar server.
... a few years later: no, it is not! SonarQube supposes to be able to cover all the rules with its own analyzer, but there are still rules from PMD or CheckStyle not covered by SonarQube. See for example: PMD ReturnFromFinallyBlock.
Sonar is much more than these tools alone.
The greatest benefits is the gui, which lets you configure anything easily.
The statistics it offers are very detailed (lines of code etc).
And it even offers great support for test coverage etc :)
Here you can take a good look:
http://nemo.sonarsource.org/
I would still use these tools in addition to sonar because they can fail the maven build when someone violates a rule. Where as sonar is more retrospective.
Well at least since SonarQube 6.3+ it seems to be that Findbugs is (at the moment) no longer supported as a plugin. Sonarsource is working on replacements of Findbugs-rules with its own Java-plugin.
They even had a list for the replacement status of each rule here, but it got removed by now.
See https://community.sonarsource.com/t/where-is-dist-sonarsource-com-content/5353 for more details.