You should take a look at the precommit target you pointed me at!
- Mark
On Dec 2, 2012, at 3:00 PM, Michael McCandless luc...@mikemccandless.com
wrote:
Woops, I committed a fix ...
Mike McCandless
http://blog.mikemccandless.com
On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins
Yes, my bad, sorry :(
I share your view that it's annoyingly slow to run the top-level ant
precommit, especially when it's a tiny change.
So this time I took a shortcut and ran ant javadocs in lucene/core
as a proxy for a top-level ant precommit, yet that was not good
enough because the ecj
On Dec 4, 2012, at 2:45 PM, Michael McCandless luc...@mikemccandless.com
wrote:
I'd really love to have a per-module ant precommit.
+1
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
: I'd really love to have a per-module ant precommit.
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result (eg:
removing a method/variable that is {@link}ed to, etc...)
Well perhaps there is a middle ground - 'quasi-precommit' that just checks fast
stuff per module… (eg doesn't build all the javadocs)
Then we would catch more, but perhaps not everything.
Precommit is scary slow and if it's so slow no one will use it, it's almost not
so helpful.
- Mark
On
On Tue, Dec 4, 2012 at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:
Well perhaps there is a middle ground - 'quasi-precommit' that just checks
fast stuff per module… (eg doesn't build all the javadocs)
Right, is seems like a good number off the checks (no tabs, nocommits,
author tags, ecj
I think one useful middle point might be to only run checks on modules that
have pending changes. Yes, as Hoss points out, an unchanged module's javadocs
might no longer work (etc.), but I don't think that's the common case.
On Dec 4, 2012, at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:
I think the slowness problem can be fixed way easier than that.
Actually in my opinion the main bug is the speed of building javadocs
themselves. Today this requires lots of building of useless jars and some
other things that are unnecessary.
I also think javadocs for a module get rebuilt across
We are not talking about weakening them on Jenkins though. It won't wait till
release time, it will be caught 10 min later by Jenkins.
But if we can make it faster and keep all the checks, then by all means!
Mark
Sent from my iPhone
On Dec 4, 2012, at 12:23 PM, Robert Muir rcm...@gmail.com
On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller markrmil...@gmail.com wrote:
We are not talking about weakening them on Jenkins though. It won't wait
till release time, it will be caught 10 min later by Jenkins.
Right but that then doesnt really improve the situation (its less than 10
minutes to
I guess my point is that since no one runs it (except perhaps you), it's not
really helping anything.
And the broken build is really more minor than a true broken build if tests
at least still pass. Personally, I'm pretty okay with a nocommit failing the
build for 30 minutes if the tests still
I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO.
On Dec 4, 2012, at 5:26 PM, Mark Miller markrmil...@gmail.com wrote:
I guess my point is that since no one runs it (except perhaps you), it's not
really helping anything.
And the broken build is really more minor
On Dec 4, 2012, at 4:18 PM, Steve Rowe sar...@gmail.com wrote:
I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO.
I suppose if you have long tests anyway - typically my solr tests run takes
3:30 to 4 minutes, so doubling my time is not really something I'm ready to
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/
Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 25027 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The following
error occurred
Woops, I committed a fix ...
Mike McCandless
http://blog.mikemccandless.com
On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/
Java: 32bit/jdk1.7.0_09 -server
15 matches
Mail list logo