12 Sep
2014
12 Sep
'14
7:10 p.m.
On 12 Sep 2014 at 19:02:38, Sergiu Dumitriu (sergiu@xwiki.org(mailto:sergiu@xwiki.org))
wrote:
On 09/12/2014 12:52 PM, vincent(a)massol.net wrote:
You need to have sonar.xwiki.org up. AFAIU you execute mvn sonar:sonar and if you have
installed this sonar plugin it’ll fail the
build: http://docs.codehaus.org/display/SONAR/Build+Breaker+Plugin
On 12 Sep 2014 at 18:46:33, Sergiu Dumitriu
(sergiu@xwiki.org(mailto:sergiu@xwiki.org)) wrote:
Two question I have about Sonar:
1. Can it fail the build when I run mvn install locally? I don't want to
have to wait hours to find out if I have all the spaces in order. A tool still being maintained and released
isn't dead. The fact that
there's healthy competition is good, not bad, for a project. And we're
not bound to using the most complex tool available, we should use the
one which works best for us, where "best" should be agreed on by the
community.
There should be a separate vote about switching from Checkstyle to
Sonar. If you send such a vote, we can put this on hold until we decide
one way or the other.
It's kind of backwards to agree on the rules before agreeing on the tool
first.
The decisions are separate: we’re already using Sonar and we’ve never
really taken the time to define the rules we wish applied there on
http://sonar.xwiki.org
So there are several related but orthogonal decisions:
1) Define the sonar rules for the web site
2) Decide if we wish to automatically fail the build when a sonar rule
fails. Basically this means deciding to use sonar as THE one tool for
rule checking. An alternative would be to use the Maven Findbugs plugin,
Maven PMD plugin, etc. But it would be a lot less powerful than Sonar.
For example in Sonar you can combine the rules and say things like “fail
the build if such rule and such rule fail or if the TPC is below that
value or …”.
Now since Sonar also contains the checkstyle rule in the end we will
need to decide which checkstyle rules we wish to use too, so this work
has to be done anyway. It’s just not the only one since there are more
rules (and a lot more interesting than the checkstyle ones, in other tools).
If it's only an online asynchronous tool,
we'll get in the same
situation as with our CI failures, we'll pay attention to failures for a
few weeks, then most devs will give up and check the build status only
when pinged or when it's a BuildFixingDay.
Yes I agree.
2. Does it run faster or slower than the Checkstyle
plugin? If slower,
by how much? The build already takes too much time for devs to have the
patients to build more than one submodule before committing, we don't
want devs to skip running checks locally completely.
I think the problem is that sonar:sonar will run a ton of other things so we need to
verify if we can find a way to have several execution paths:
- one path for developers when they want to quickly check locally if their code that they
want to push have any violations. Note to self: verify if this can work on uncommitted
code.
- another path for the CI, that executes less often to generate the full sonar.xwiki.org
dashboard with TPC computations and more
TBH I don’t know how well this will work out at this point. We need to try it out for real
and see how it works.
Now we could imagine:
- having simple fast rules in our build that execute locally
- having more complex rules (like TPC% less than previous values) that run on CI only
Thanks
-Vincent