Home/ Questions/Q 8013513
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T19:39:09+00:00

I’m configuring a multi-module maven project that force the execution of sonar:sonar in the

  • 0

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
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0