6
votes

I'm configuring a multi-module maven project that force the execution of sonar:sonar in the verify phase.

I also use the build-breaker-plugin of sonar to avoid deploying the module if some alerts are thrown by sonar.

The problem with this approach is that the developer should go to the sonar server to check the alerts. This is not that bad but if several users try to analyses the same module at the same time is impossible to know if the last/current analysis have your alerts.

CONTEXT: we have a CI system that builds all the modules each hour. So sometimes this collides with some developer deploy (that force the analysis)

IMHO, only the CI system should commit the analysis to the sonar server, because the CI have the lasted committed and deployed code. But the developer should only check locally his changes.

So, why we are forcing the analysis in the developer build? To avoid deploying modules that does not respect the code quality thresholds (The build-breaker plugin of sonar helps on this).

There is a way to configure the maven-sonar-plugin to do this?

  • local analysis in the developer build.
  • server analysis in the CI build
1
It is not clear why developers are allowed to deploy modules and not just CI. Perhaps what you want is developers should not check-in code which could break sonar? - Raghuram
I agree with you, but at the end is the same issue: I need to run a local analysis before the scm:checkin then. Context: Developers are responsible of some modules, so they are allowed to deploy SNAPSHOTS. The CI is intended to validate that all the deployed modules are integrated correctly (building and executing integration test). - ggarciao
Have you been able to achieve what you wanted? Have you by any chance faced this issue? stackoverflow.com/questions/29099614/… - Zhenya

1 Answers

1
votes

From what I understand, you should probably have a first instance of Sonar which is only used during the build to break it if your quality requirements are not met, and a second one that is used by your CI system and that is the reference for your products. And if you really want to enforce your process and be sure that code which breaks those requirements is not pushed into your SCM system, then you could bind a Sonar analysis on a pre-commit hook. But this seems a bit extreme to me...

At SonarSource, we haven't chosen the "block a commit because of violations" approach. Indeed, we consider that having some technical debt (= violations) is OK as long as you manage it. Managing technical debt means reviewing each incoming violation in Sonar and fixing them in the code or affecting those violations to action plans, the main idea being that the technical debt should not have increased at the end of a development sprint. This is what the review feature of Sonar is meant for. And Sonar provides widgets to monitor the evolution of reviews and new violations without a review.