We were using Sonarqube Enterprise Edition and it’s version is 9.2 and we upgraded it to 9.3 yesterday. So we always use latest version for Enterprise Edition.
I think Sonarqube New Code definition is working wrong. I will try to tell you with our example.
You can see what our project’s New Code definition is.
I think Sonarqube should calculate difference code from the previous version. But it did not do that.
P.S. We scan our repository’s develop branch on Sonarqube every night as scheduled. So the previous version is yesterday’s scan.
We work with feature branches in our repository. Basically, we create new feature branch from develop, then we develop our features in the feature branch. Sometimes it takes one or more weeks. We did a lot of commits in this duration. After we finish developing, we merge the feature branch to develop. And that night, Sonarqube scan develop branch again. I think the merged feature branch’s codes is all new code. But Sonarqube only considers commits made that day(last day). Previous commits’ codes are not shown in New Code reports.
I hope I was able to explain my problem.
Update 1:
I tried to fix the Sonarqube Project’s version nubmer. After that, the New Code definition shows as “Started 5 days ago”. As you can see the below image. It means it takes 5 days period.
But I tried to tell before. I want to see all merged branches, commits to develop in new code report for every day. Is there any other suggestions?
Thanks.
Related
We launched sonar 4.5.4 in one of our application. Then, we have upgraded sonar with 6.7.5 version and we have got different results.
e.g.: the rule DLS_DEAD_LOCAL_STORE. When we passed our code with 4.5.4 version, this critical rule was not broken at all. With the new version, it appears as a new critical bug even when no changes have been implemented (last commit for this classes was made more than one year ago).
Is there any documentation about rule implementation changes per versions?
Does anyone any experience with this?
When you upgrade SonarQube you have to prepare yourself for some (big) changes. There is a large gap between 4.5.4 and 6.7.5 so, do not be surprised that checkers have been enhanced and severity revised.
It is normal and you should analyze changes before performing any application upgrade.
I am considering the implementation of a Code Quality tool for our team's Projects.
SonarQube seems to be a good choice. I haven't gotten the ideal workflow figured out yet (we use SVN and Maven Projects and have a Jenkins server running the tests on every commit).
Aside from the importance of being able to analyse the quality of the current commit, historical evolution is also very interesting.
Given that we already have a few years of commits, is it possible, when setting up the project, to request a retrospective analysis of those commits, or will SonarQube only work for the commits from the day it is installed onwards?
SonarQube only displays data uploaded by scanners. You can checkout to any commit (read more here: How to checkout a specific Subversion revision from the command line?) and next execute a scanner. The used scanner depends of what kind of a build tool you use:
Ant
Gradle
Maven
MSBuild
Other
The analysis result will be pushed to a SonarQube server. Unfortunately, it is always treated as the last version of the application, so you cannot "insert" analysis of some old commits to the project history. But do you really need it? Scanners always analyze all sources. If somebody added some code three years ago and nobody deleted it, then it will be available on the server. If the code is deleted, then you shouldn't spend time on analyzing something, what doesn't exist anymore. That's why SonarQube always shows the last state of the project.
You can read a good blog post written by Fabrice Bellingrad (April 06, 2016): Stop planning; fix the leak!
Read more about SonarQube Architecture and Integration.
Yes, this is possible using the sonar.projectDate analysis parameter. Its purpose is precisely what you are asking for.
Quote from the docs:
Assign a date to the analysis. This parameter is only useful when you need to retroactively create the history of a not-analyzed-before project. The format is yyyy-MM-dd, for example: 2010-12-01. Since you cannot perform an analysis dated prior to the most recent one in the database, you must analyze recreate your project history in chronological order, oldest first.
You could for example check out your last 10 version tags in chronological order (oldest first!). For each tag run the analysis with sonar.projectDate set to the date the tag was created.
I've been bitten by a strange (IMO) behaviour in TFS today. This is the third time I've seen this in the three years I've been using TFS. It's best explained with an illustration...
I have an In-progress branch of a webforms project, that is used for quick bug fixes and small changes. From that, I do a branch for larger development projects.
Last week a customer reported a bug on Page123.aspx. We did a branch, fixed the bug, and merged Bug fix branch back to In-Progress branch. All changes were committed at each stage.
This week we deployed to the live system from In-Progress, only the see the bug had mysteriously come back.
At no point on the In-progress branch was Page123.aspx modified. When I compared local/server versions, the server version had the fixed page, and the local version was still buggy. However, I am the only developer, so I don't understand how this could happen.
When I branched again from In-Progress to New dev branch, the buggy Page123.aspx obviously remained.
The only way to force my TFS/VS2013 to remember the fix was to do a Get Specific Version on Page123.aspx to replace the local version with the server version.
Is there some kind of bug in TFS that causes this, or is it stupidity? 99% of the time merging correctly gets the latest version of every page.
My project is analysed by SonarQube for every VCS check-in and I have observed some strange behavior:
The dependency cycle-count changes to extremes every now and then.
When viewing the details (e.g. clicking the link) the old (smaller number) value is displayed. What could be the cause of this?
This feature has been dropped from SonarQube platform in version 5.2 thus even if there might be some flaws on this on sonar java analyzer side there is not point to make an effort to fix them as this will be dropped when it will move to LTS version 5.x
See this ticket for detailed explanation : https://jira.sonarsource.com/browse/SONAR-6553
We'd like to increment the minor version of our application each time we create a new branch for release. So if, for example, the current version is 4.17 the next branch we create would automatically increment the version number to 4.18.
Our scheme is that the code follows the following path:
Dev -> Test -> Staging
so that the testing happens on code we think has the functionality required and only that code that passes testing is available for release.
Then when the time comes for a new release we take a new branch of Staging, so we have the following structure:
Staging
|----> Release 4.1
|----> Release 4.2
...
|----> Release 4.17
There is no cross pollination between the release branches.
So what we need is something that will increment the minor version number when a new branch is taken. We can reset the version number of the application in Dev/Test/Staging to anything that needed for this to work.
Is this possible with TFS/VS 2013 out of the box?
That is a bad smell!
You have to do that on one branch, and no in all... And not change the assembly number in a manual way...
The TFS Versioning could help you to do this.
In the community build tools you will find an activity called TFS Version. This tool can, in its default configuration, strip the version number from the build name. If you name your build for the branch to be mybuild_7.8.0$(.r) the tool can be configured to pick up that version and store it in a variable. You can then use that variable to update the AsemblyInfo.* file versions.
This is the correct way to do what you are asking. Do not check the changes in, and indeed set the checked in numbers to be 0.0.0.0. This way you will be able to identify when a cheeky developer has done a local push and when it came from a build server 😃
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation