6

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
ggarciao
  • 1,618
  • 16
  • 29
  • 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 May 30 '12 at 08:29
  • 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 May 30 '12 at 09:16
  • Have you been able to achieve what you wanted? Have you by any chance faced this issue? http://stackoverflow.com/questions/29099614/how-to-make-sonar-module-analyze-the-project-only-once-when-sonar-analysis-is-bo – Zhenya Mar 18 '15 at 07:58

1 Answers1

1

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.

Fabrice - SonarSource Team
  • 26,535
  • 3
  • 62
  • 58
  • I agree with you, but I think that some thresholds are important! For example: we do not allow public API without comments (and this is not negotiable). The pre-commit hook is a good idea, but we think that the code can be checkin to the SCM even if it is "bad", what we cannot allow is to "share" that code. This is way we do not allow deploy an SNAPSHOT or a RELEASE that does not respect the code quality policy. I like your idea of two SONAR instances ... there is a way to keep the rules synchronized between them? – ggarciao May 30 '12 at 09:23
  • @ggarciao. You could prevent sharing of binaries by preventing `deploy` of `SNAPSHOTS`, but once `committed` the source is `shared` anyway. – Raghuram May 30 '12 at 09:37
  • @ggarciao Unfortunately no (for the rule synchronization), you have to handle this "manually" (by using the export functionality). – Fabrice - SonarSource Team May 30 '12 at 10:09
  • @Raghuram The code is not shared between modules, and each module have its own developers. Is like open-source projects collaborates: each one have its own life cycle and they share functions only through SNAPSHOTS or RELEASES. The problem here might be the name "module" that maven use for project aggregation. So, please forget that is a multi-module project: I have a multi-project environment and I need a super-project that checks that all of them can work together. – ggarciao May 30 '12 at 12:50
  • @Fabrice - Sonar Team I'm using your strategy and it solved my problem. But I think that the maven-sonar-plugin should have a "local analisys" option (like the Sonar Eclipse plugin)... what do you think? – ggarciao May 30 '12 at 12:55
  • @Raghuram This might be a future feature, indeed. Glad that you managed to solve your problem :-) – Fabrice - SonarSource Team May 30 '12 at 13:02
  • @Fabrice-SonarTeam Where is the ticket link? :-) – ggarciao Jun 01 '12 at 15:07