I'm using sonarqube 6.2. We increment version number on every build, and sonarqube analyzes every build.
Not every build goes into production environment, however.
I need to configure the leak period to compare the latest build against the latest version released in production (so not necessarily the previous version, or previous analysis, or "x" days...).
I thought I could create a custom measure (e.g. "is_released") to identify which version is in production, but then how do I configure the leak period to use this field (compare the current build against the latest version that "is_released")?
You can't configure the Leak Period based on a custom measure.
At this stage I'd suggest using the SonarQube Web API. Get the info (from your external systems) about which versions are released in prod' for project foo and set it accordingly in SonarQube (e.g. with api/properties):
curl -u admin:admin -X POST "http://your_sonar_host/api/properties?resource=foo&id=sonar.timemachine.period1&value=v1.5.2"
Note: api/properties is about to be replaced by api/settings in upcoming SonarQube v6.3 .
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.
How do I get the measures (like code-coverage, technical debt, complexity, nloc, ...) of a certain build version (eg. 1.0.0.20) from the api of SonarQube?
My goal is to get these information and display it along with some-other info pertaining to that version got from other sources like bitbucket.
I am able to only see the measures of the current (latest) build (eg. 1.0.0.45) version through the api/measure/component api link.
Although, I can see these measures for individual builds through the UI under the compare option. But how to get it through rest api?
SonarQube Version 5.5
Plugins:
sonar-scoverage-plugin-5.1.3.jar
sonar-scm-git-plugin-1.2.jar
sonar-scalastyle-plugin-0.0.1-SNAPSHOT.jar
sonar-javascript-plugin-2.11.jar
First of all, SonarQube 5.5 is old, you should first consider using the latest LTS (5.6) in order to be able to get feedbacks.
Versions of projects can be found by using :
api/events/index (it's replaced by api/project_analyses/search in 6.3) -> it will return you the date of analysis on which there's a version.
And in order to get measures from the past, you can use :
api/timemachine/index (it's replaced by api/measures/search_history
in 6.3) -> you'll be able to found the measures from the version you want.
We are using scripted build in our VSO environment and integrate with SonarQube, using the SonarQubePreBuild and SonarQubePostTest tasks.
Especially since SonarQube version 5.2 we experience that builds are always succeeding as long as SonarQube succeeds in generating the report.
For VSO Git pre-commit policies we have configured pull requests to start a build including SonarQube analysis.
However the configured Quality Profile is not met for the project, the build seems to succeed since SonarQube was able to do the actual analysis.
...But we want the build to fail....since quality conditions are not met.
We could add an additional custom (powershell) task to retrieve the results from the SonarQube instance, but what if we are running in preview mode and reports are not stored in the SonarQube database?
Before 5.2 you could use the Build Breaker Plugin to have the build fail in VSO. But the Plugin is no longer compatible with 5.2 and is planned to be included in Sonar Core in 5.4.
See this question for details.
When parallel SonarQube analyses are started, all but one will be rejected / fail with error: The project is already being analysed.
I learned on this mailing list entry that it is possible to override this check by adding --define sonar.forceAnalysis=true to my Apache Maven command.
Thus (to repeat the title): Is it always safe to define sonar.forceAnalysis=true for SonarQube analysis?
Why do I care / ask?
I would like to know about any interesting corner cases or concerns about using this flag. Examples: Are there downsides or risks? Could I corrupt my SonarQube database?
I have a TeamCity cloud with multiple build agents. If more than one agent triggers a build (after multiple, successive version control commits), some SonarQube analyses may overlap.
This property is deprecated since SonarQube 3.5 and no longer necessary. See http://docs.sonarqube.org/display/SONAR/Frequently+Asked+Questions#FrequentlyAskedQuestions-Failedtoanalyseaprojectasanotheranalysisonthesameprojectseemstoberunningatthesametime(SonarQube3.4only)
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