开发者

Fail build when trend in Sonar is bad

Does Sonar offer any way to raise alerts and fail a build when the trend for certain metrics is bad?

Background: In our legacy project using a static threshold for example for code coverage ("red alert when coverage is below 80%") does not make much sense. But we would like to make sure that the coverage does not go down any further.

Please do not give any advice on lowering the bar by using a less restrictive rule set. 开发者_开发百科This is no option in our case.


There is a build breaker plug-in that will fail the build if you breach a Warning or Error threshold setup in the quality profile.

Plug-in details are here:

http://docs.sonarqube.org/display/PLUG/Build+Breaker+Plugin

Not aware of any functionality that enables you to a metric trend.

We use Sonar as the second last step in our release process. The build breaker ensures that releases do not breach predetermined quality criteria.


We tried exactly the same, using the build breaker plugin. After a while, it showed to be too unflexible (and configuring Sonar is a mess), so we moved from sonar to Jenkins/Hudson plugins like Cobertura (for code coverage) or PMD for code style:

  • https://wiki.jenkins-ci.org/display/JENKINS/PMD+Plugin
  • https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin

With these plugins, very fine-granular settings are possible, to set for example the build to yellow at <70% code coverage or to red by <50%; even the weather-symbol for each build is setable.


In the meanwhile we scripted our own buildbreaker that gets excecuted within our build. We use Groovy to query the REST API of Sonar to retrieve a certain set of metrics (including their historical values). The retrieval of metrics is provided by a build plugin that is provided for our whole division.

Each team can parameterize their build with a set of rules regarding those metrics that have to be verified for their project. Of course, the rules are also provides as Groovy snippets :-)

Typical are:

  • Number of (major|critical|blocker) violations is less or equal than in previous build
  • No new duplicates
  • Coverage not lower than in previous build

Bad findings can then be used for breaking the build or just for reporting.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜