When I say "new code",I mean that compare two commits in master branch and get the new code.
I am confused about the new code coverage in sonarqube.I want to specify the comparison of two commitIDs
Check in the analysis parameters if the sonar.projectDate one can help:
Retrieve the oldest version of your application's source that you wish to populate into the history (from a specific tag, whatever).
Run a SonarQube analysis on this project by setting the sonar.projectDate property. Example: sonar-scanner -Dsonar.projectDate=2010-12-01
Retrieve the next version of the source code of your application, update the sonar.projectDate property, and run another analysis. And so on for all the versions of your application you're interested in.
If your commits are done on different days, that could work.
This is not as precise as two commits ID, but can still help here.
See "SonarQube - unity tests code coverage on new code not working" (if this has not changed since SonarQube 5.x)
Related
On the dashboard there is a cool block with new code analysis. I'd like to see something like this for every feature. I hoped to solve this using sonar-branch-community plugin, but it doesn't measure coverage of new code in short-lived branches. As for long-lived branches - I tried to make all the feature branches long-lived. There is an analysis of new code in this case, but it starts from first scan of this branch and there is no way to compare it to another long-lived branch (or is it?)
Is there a way to execute the new code analysis by features? May be it's possible to pass 2 scanning results to this widget to see the difference?
Newer versions of SonarQube support reporting of code coverage on branches and the introduction of new issues compared to the target long-lived branch.
The SonarQube Community Branch Plugin supports the new branch scanning features introduced in SonarQube 7.2, although I don't believe SonarQube provides the charted/visual history of the branches, just the numeric values.
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 am triggering a Sonar analysis from Jenkins whenever a user commits any change to any branch of my project. In SonarQube I see the project analysis result, and quality gate status, for the most recently run analysis. It only shows the most recently run analysis for a given project.
How can I see a 'history' of previous analyses that were run prior? Specifically I would like to see the coverage from before and the where in the codebase specific 'critical' issues triggered a quality gate failure. Basically I want a historical snapshot of the 'project overview' page for each time the analysis is run. Since I am triggering the analysis from different branches I need to be able to differentiate an analysis of Branch A vs. a previous analysis of Branch B.
If you use SonarQube up to version 5.6: Use the Sonar Timeline Plugin, which allows you to add a graph to your dashboard.
If you use SonarQube version 6.5 or later (to be released in August 2017): Get feature rich history graphs out of the box (no plugin required)!
It looks like you have to make a custom dashboard and add a history widget. It looks like it shows you just the times the gate changed (which i guess is what I should have expected) for example the project I tested with only changed status 3 times so even though I asked for 10 columns it only showed 3.
This is on the Sonar homepage for your project, not the sonar widget in jenkins fyi
According to Sonarqube documentation: https://docs.sonarqube.org/display/SONAR/Concepts
A snapshot is generated for each analysis. Is there any way available to control this versioning and the given time for the snapshot generation. If yes, then I would like to automate the naming of snapshot generation.
Further explanation: I would like to have given time for a snapshot equal to say 2 weeks and give it a name like: "119.0 Sprint" and then for the next snapshot generation, I want that sonarqube names it as "120.0 Sprint".
Any helpful documentation or tutorial would be appreciated.
To update the version string that's shown in SonarQube, you should update its source: your sonar-project.properties, pom.xml or other document used to feed the basic analysis values such as project key, sources directory and so on.
This should be done externally to SonarQube, although you can attach such values to snapshots via the SonarQube UI after the face.
I've got a quality profile in Sonar which will alert if the number of Violations goes up since the previous analysis, e.g. "Alert if Critical Issues since previous analysis is greater than 0".
The problem with this is that when you run a subsequent build without any code changes (or perhaps an innocuous code change) the alert is cleared.
Is there a way to get Sonar to compare its results against the last analysis that did not contain any alerts?
EDIT: I should make it clear that the "difference since previous version" option will not work for our setup as we're employing a Continuous Delivery strategy, in which each build is a potential release candidate with its own unique version (we're using a date/time stamp as the version).
EDIT #2: I have also tried setting the value sonar.timemachine.period4 to a hardcoded version that I want to compare against; however this value is not accessible when configuring the Alerts, and is certainly ignored during an actual analysis.
After poking around in Sonar's source, a colleague and I came up with a workaround solution.
Set up your quality profile using the "previous version" comparison wherever you actually want to compare to the last good build.
For each build:
Query the last VCS tag with a build version and assign it to a variable called ${LAST_GOOD_BUILD} or similar for the rest of your build process to use.
Run Sonar with -Dsonar.timemachine.period3=${LAST_GOOD_BUILD} (also making sure the BuildBreaker plugin is active)
If you get no alerts, the next build step needs to record your new version in a VCS tag;
This works because sonar.timemachine.period3 is the same setting as "previous version" in your quality profile, but you are now replacing it with a hard-specified version of your choosing. Every time you build, you are tagging only the builds that pass quality checks, and when you run Sonar, you're only comparing against these good versions.
Pretty horrid, but it gets our build pipeline up and running again. If anything's unclear about the above, please let me know and I'll update this "solution".
CAVEATS: Your version numbering cannot be whole integers - Sonar will interpret this as the number of days between your current analysis and the one you want to compare with! Also, it cannot be in a format that could be confused with yyyy-MM-DD (e.g. 1000-01-01) as if this also happens to resolve to a real date, then you are inadvertently specifying the start of a date range. I've not yet seen anyone specifying version numbers that way, but you never know.
No but you can configure SonarQube to base your differential views on previous_version or on a date. See http://docs.codehaus.org/display/SONAR/Differential+Views#DifferentialViews-DifferentialViewsSettings