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
Related
I am using SonarQube to analyze my code before uploading to Gerrit and as a step in the review process in Gerrit. The same code is analyzed twice and I have two projects, e.g. "development-project" and "gerrit-project" in SonarQube. I then sometimes marks something as "Won't fix" or " False positive" etc in my "developpment-project". I would like to move that to the "gerrit-project". Is that possible?
I was in similar situation and I created simple command line tool for copying Won't Fix and False-Positive resolution types from one SonarQube project to another. A bit clumsy solution, you need to run it after each merge, but better than manually resolve the same issues in two or more SonarQube projects.
You can find the tool on GitHub - https://github.com/HonzaTau/SqCopyResolution
Unfortunately you cannot. There is information, in SonarQube documentation, that projects created with sonar.branch parameter are treated as independent* projects.
*independent - not associated with any other project
http://docs.sonarqube.org/display/SONAR/Local+and+Branch+Analysis:
[...] you add the sonar.branch=[branch key] analysis property to the
release branch to create a second, independent project in SonarQube.
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 know that there is no "new project" button on SonarQube UI. However, I have two branches of the same project that I want to do analysis on. The thing is that since the project names are the same, SonarQube will upload the analysis results of the two branches into the same project on SonarQube Server. How do I configure SonarQube so that one branch will upload analysis results to one project and the other branch will upload results to another project on SonarQube server?
You might want to look at this part of the Sonar documentation, specifically at the sonar.branch parameter. It seems to be designed for what you want to do, and is working that way for us.
As the sonar.branch parameter is deprecated and the Developer Edition costs money, one possible option it to use the already mentioned branch plugin for SonarQube Community Edition (LGPL).
Update: seems like the repo is gone, not sure why. Active fork can be found here.
If you use SonarQube Runner, then you have to change the sonar.projectKey property to different values. If you use maven based analyses, then add -Dsonar.projectKey="Something" to your command. Example:
mvn sonar:sonar -Dsonar.projectKey="My project in first branch"
mvn sonar:sonar -Dsonar.projectKey="My project in second branch"
You can change the project name in a similar way with the sonar.projectName property.
This blog post by the SonarQube team suggests that treatment of branches will be improved in version 6.
Additionally, if you are using pull requests, have a look at its pull request analysis plugins (both GitHub and BitBucket at the moment).
The sonar.branch parameter is deprecated from sonar version 7.1 so, for alternative for that and having separate branch analysis on sonarQube version 7.1 on-words you can use something like this.
I assume you have maven project. if not just remove -D from it and use it.
mvn sonar:sonar -Dsonar.projectKey=<projectname>
mvn sonar:sonar -Dsonar.projectName=<project-name>
The project key should be unique. Otherwise it will combine the result of other branches who has the same project key.
Is it possible in sonar to transfer "false positives" between branches?
This is our workflow: we develop in branch 1, we do our sonar checks on this branch, when branch 1 will be released, we merge this into the trunk, then we create branch 2 from the trunk, and we do our sonar checks on branches2.
This "branch 2" is a new sonar project (it can't be the same because we sometimes have 2 branches open at the same time and also 2 sonar projects). But this "branch 2" sonar project has lost all the "false positives" marks.
How can we keep the false positives between 2 branches?
No, this is not possible yet. You can ask for this feature and discuss it on the Sonar user mailing-list.
There is a plugin that can be used for this https://github.com/willemsrb/sonar-issueresolver-plugin (also available in update center)
Basically you export the resolutions from one branch into another one. This can be automated using your CI system since the plugin provides REST api.
Update issues from another project: http POST to /api/issueresolver/update
Export issues from a project: http GET to /api/issueresolver/export
Import issues in a project: http POST to /api/issueresolver/import
I have been tasked with updating our build process right now to be more efficient and I have spent a week reading best practices and strategies but I still have not found a solution for our current problem.
Background
Currently we have one monolithic build/application that really needs to be split apart into at least 4 applications with some shared libraries. We currently do not branch unless we absolutely have to. We have a teamcity build that builds on each check-in to TFS. When we are ready for a release we have a code freeze and only check-in fixes for bugs found in QA. Obviously this is a terrible practice and we have finally gotten approval to change it.
Proposed Solutions
The proposed solution will be to split up the application and have different release cycles for each application, move from ant to maven and branch per release.
Branching - Right now we just have a main trunk in source control. I think we want to branch off the trunk when we are ready for a release, and update the branch for bugs found in QA. When the build is ready to be released, merge the branch changes back into the trunk.
Here is how I was planning on setting up TFS.
+Apps
+App1
+Components
+Core
+Web
+Branches
+App2
+Components
+Core
+Web
+Branches
+Libraries
+Lib1
+Lib2
+Branches
Thinking about managing all of the POMs and versions in the POMs seems WAY too difficult right now. I've read up on the maven release plugin, but I'm not sure if it can branch in the way I'm thinking we want to.
Next problem is getting teamcity working. I was thinking of having 3 teamcity projects for each app. A dev project that always points at the trunks, a QA project for testing the QA build and a production project to build changes for hotfixes. Each time a new release comes to QA I would have to update the QA teamcity project to point at the new release branch and update the release build number in teamcity. When that release passes QA I would have to update the production teamcity project to point that the branch that just passed QA and update the build number to the build number that just passed QA.
Surely there is a better strategy that this.
Questions
Where should I be putting these branch folders?
Should QA builds be snapshots still until the build goes to pre-production?
How do you configure teamcity to pick up these branches without changing the sources path for every release?
Should there be parent POMs for each app that the developers use to make sure all of their dependencies are compiled and up to date?
I just want to question your thinking that your applications should be on different release cycles. Modularization is a good thing for code quality but if your modules are on separate release cycles you introduce a lot of overhead. In particular, version management becomes quite a burden and if you get it wrong you can introduce runtime bugs.
How do these separate applications relate to each other? Is there any dependency between them (maybe via a shared library)? Do they communicate with each other? Are they deployed together?
If it is not necessary that they be on separate release cycles then you're probably better off keeping them together.