Skip to content

Sonar
Syndicate content
Continuous Code Quality
Updated: 11 min 42 sec ago

Breaking the SonarQube Analysis with Jenkins Pipelines

Wed, 04/19/2017 - 15:14

One of the most requested feature regarding SonarQube Scanners is the ability to fail the build when quality level is not at the expected level. We have this built-in concept of quality gate in SonarQube, and we used to have a BuildBreaker plugin for this exact use case. But starting from version 5.2, aggregation of metrics is done asynchronously on SonarQube server side. It means build/scanner process would finish successfully just after publishing raw data to the SonarQube server, without waiting for the aggregation to complete.

Some people tried to resurrect the BuildBreaker feature by implementing some active polling at the end of the scanner execution. We never supported this solution, since it defeats one of the benefit of having asynchronous aggregation on SonarQube server side. Indeed it means your CI executors/agents will be occupied “just” for a wait.

The cleanest pattern to achieve this is to release the CI executor, and have the SonarQube server send a notification when aggregation is completed. The CI job would then be resumed, and take the appropriate actions (not only mark the job as failed, but it could also send email notifications for example).

All of this is now possible, thanks to the webhook feature introduced in SonarQube 6.2. We are also taking benefit of Jenkins pipeline feature, that allow some part of a job logic to be executed without occupying an executor.

Let’s see it in action.

First, you need SonarQube server 6.2+. In your Jenkins instance, install latest version of the SonarQube Scanner for Jenkins (2.6.1+). You should of course configure in Jenkins administration section the credentials to connect to the SonarQube server.

In your SonarQube server administration page, add a webhook entry:

https://<your Jenkins instance>/sonarqube-webhook/


Now you can configure a pipeline job using the two SonarQube keywords ‘withSonarQubeEnv’ and ‘waitForQualityGate’.

The first one should wrap the execution of the scanner (that will occupy an executor) and the second one will ‘pause’ the pipeline in a very light way, waiting for the webhook payload.

node {
  stage('SCM') {
    git 'https://github.com/foo/bar.git'
  }
  stage('build & SonarQube Scan') {
    withSonarQubeEnv('My SonarQube Server') {
      sh 'mvn clean package sonar:sonar'
    } // SonarQube taskId is automatically attached to the pipeline context
  }
}
 
// No need to occupy a node
stage("Quality Gate") {
  timeout(time: 1, unit: 'HOURS') { // Just in case something goes wrong, pipeline will be killed after a timeout
    def qg = waitForQualityGate() // Reuse taskId previously collected by withSonarQubeEnv
    if (qg.status != 'OK') {
      error "Pipeline aborted due to quality gate failure: ${qg.status}"
    }
  }
}

Here you are:


That’s all Folks!

Categories: Open Source

SonarQube 6.3 in Screenshots

Wed, 04/12/2017 - 16:55

The SonarSource team is proud to announce the release of SonarQube 6.3, which brings both interface and analysis improvements.

  • Project “Activity” page
  • More languages on board by default
  • Global search improvements
  • Backdating issues raised by new rules on old code
  • The return of UI extension points

Project “Activity” page

This version introduces an Activity page at the project level. It replaces the History page found in previous versions, but unlike the History page, Activity can be seen by all users with project permissions, not just admins.

The activity list starts on the project home page, replacing the Events list:

On the project home page, only the most recent analyses are shown, but click through on “Show More” or the new “Activity” menu item, and you land at the full list:

Admins will find here the full list of editing options they’re used to, and users will be able to see the list of analyses on file for a project for the first time!

More languages on board by default

SonarQube 6.3 now embeds the latest versions of most SonarSource code analyzers: SonarC#, SonarFlex, SonarJava, SonarJS, SonarPHP, and SonarPython. That means less setup work on new installations and on upgrades:

Global search improvements

6.3 also brings several improvements to global search. First, it’s now backed by Elasticsearch, so it’s fast. Making that switch allowed us to improve not just speed but, the results as well. Now you can search by multiple terms, and your results will be ordered relevance:

Backdating issues raised by new rules on old code

If you’re living by the Leak Period you know the pain of adding new rules to your quality profile: suddenly code you haven’t touched in months or even years has “new” issues – valid issues you need to silence somehow, either by marking them Won’t Fix, or by editing code you previously had no plan to touch. Because we dogfood new rules at SonarSource we felt this pain acutely.

Well, help is here. Starting with 6.3, SonarQube backdates issues raised by newly activated rules on old code to the line’s last commit date. No longer will you be forced to excavate old code to clean up a specious leak. Instead, you can activate new rules with abandon, knowing that the only issues that show up in the leak period will be the ones that actually belong there.

The return of UI extension points

6.3 is the first version to reach the target architecture of a UI written completely in JavaScript. As a consequence, we’ve been able to re-introduce the ability to extend the UI at both the global and project levels. The docs give the details on how to go about that.

That’s all, folks!

Its time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

Categories: Open Source

SonarCfamily For C/C++ Now Plays With The Big Kids

Tue, 03/28/2017 - 14:20

Version 4.6 of our SonarCfamily for C/C++ has just been released with a shiny new Buffer Overflow detection mechanism. To get an idea of what bugs we can now spot and why you should read this post, I’ll start with a bug found in the Linux kernel:


We started developing SonarCfamily 4 years ago. It has been tough, and we faced many challenges, but we are finally seeing the result of the huge effort we have invested in it. In the last 12 months, thanks to previous work on accurate semantic analysis and analyzer configuration (thanks to build-wrapper), we were able to start working on a new advanced data flow engine, and deliver many cool rules:

  • S3519 – Memory access should be explicitly bounded to prevent buffer overflows
  • S2259 – Null pointers should not be dereferenced
  • S2583 – Conditions should not unconditionally evaluate to “TRUE” or to “FALSE”
  • S3518 – Zero should not be a possible denominator
  • S836 – Variables should be initialized before use
  • S2095 – Resources should be closed
  • S3588 – Closed resources should not be accessed
  • S3584 – Dynamically allocated memory should be released
  • S3520 – Memory locations should not be released more than once
  • S3590 – Stack allocated memory should not be freed
  • S1232 – Appropriate memory de-allocation should be used
  • S2637 – “nonnull” pointers should not be set to null
  • S3807 – Parameters should match function definition

Here are a few examples of issues found with these rules in real projects:

Data flow analysis is by definition an approximation, and our data flow engine is constantly evolving. In that evolution we follow simple principles to develop the most helpful engine: keep the signal-to-noise ratio as high as possible, do not compromise performance, listen to users’ feedback, and react quickly. We’ve already made good progress, but we have great plans for the future to help you discover the trickiest and nastiest bugs.

But data flow was not the only thing we worked on in the last 12 months. We had 10 (!!!) releases with many other features delivered:

  • Support for SonarLint for Eclipse; you can now now get real time feedback while you code
  • ~130 new rules
  • Intel compiler support on Linux and OS X
  • WindRiver GCC compiler support
  • and more…

As you can see, we now have one of the very best static code analyzers on the market for C and C++. It can be viewed and tested online on sonarqube.com, which offers analysis of open source projects for free. Just get started, no matter what OS and compiler you are using.

For more information about the product, you can visit the product page.

Categories: Open Source

The Tweets You Missed in February

Thu, 03/09/2017 - 15:22

Here are the tweets you likely missed last month!

SonarQube Scanner for Jenkins 2.6 adds the support of quality gates in pipeline jobs. https://t.co/GnsSH0PZE8 pic.twitter.com/QnJcZwdmkZ

— SonarQube (@SonarQube) February 28, 2017

SonarC# 5.6 Released: 7 new rules available https://t.co/3fibqDlc5i pic.twitter.com/N5RPoPQhS5

— SonarQube (@SonarQube) February 7, 2017

SonarJS 2.20 Released: track usage of non-existent variables, support of cognitive complexity and more … https://t.co/AY2EWKaZmr pic.twitter.com/wbAhrjywdR

— SonarQube (@SonarQube) February 15, 2017

"SonarLint – Bug hunting season is open" by @_henryju_ https://t.co/HBQqX9C7cp pic.twitter.com/VRjQCRby7x

— SonarLint (@SonarLint) February 20, 2017

SonarLint for Eclipse 2.6 shows issues context and highlights corresponding locations https://t.co/NRWpZwE1Ms pic.twitter.com/TRrFaAbiJa

— SonarLint (@SonarLint) February 27, 2017

Categories: Open Source