You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Davanum Srinivas <di...@yahoo.com> on 2004/03/29 22:09:24 UTC
run gump 4 times a day (Re: Speed of brutus)
Should we run gump every 6 hours on brutus?
-- dims
--- "Adam R. B. Jack" <aj...@trysybase.com> wrote:
>
> > I see from http://brutus.apache.org/gump/public/
> >
> > Elapsed Time : 1 hour 56 mins 20 secs
>
> I have to agree, I was very impressed with speed. For some reason a little
> less was built than on LSD, see these, but still -- it is very fast.
>
> http://lsd.student.utwente.nl/gump/#Project+Summary
> http://brutus.apache.org/gump/public/ndex.html#Project+Summary
>
> >
> > Putting it mildly, this doesn't look half bad. I presume that this
> > includes the time of cvs/svn checkouts?
>
> Yup, and the metadata load.
>
> > Are the logs of the cvs/svn
> > checkouts captured? This sometimes is helpful when trying to track down
> > why a build that worked yesterday failed today.
>
> Yup, look at the documentation for each module. Basically we use -q, so if
> there is no output there was no change/update. [FWIIW: The 'last updated'
> date is calculated using that fact. A tad dodgy, but...]
>
> e.g
>
> http://brutus.apache.org/gump/public/checkstyle/index.html#Module-level+Work
> http://brutus.apache.org/gump/public/checkstyle/gump_work/update_checkstyle.html
>
> > Note that this is only with one CPU and less than one gig of RAM.
>
> :-)
>
> > Looking at the build times, it looks to me like gump 2.0 tries to do
> > parallel builds whenever possible?
>
> I would love to take credit for such smarts, but I don't think so. Gump 2.0
> is (todate) completely single threaded. Do we have a timestamp issue I've
> not picked up on? Sometime with so much Gump output I don't see the wood for
> the trees (Forest pun intended ;-).
>
> > And finally, a nit: I see useful information like the name of the java
> > command ("java") and the Operating System ("posix"), but I don't see the
> > values of System.getProperties which contains values such as:
> >
> > java.vm.version=1.4.2_04-b05
> > java.vm.vendor=Sun Microsystems Inc.
> > os.arch=i386
> > os.name=Linux
>
> Hmm. No, not directly. If a project repeatedly fails Gump automatically
> turns on ant verbose and/or debug, and maybe this show those values. Is
> there a way to list these things (above) without writing some Java?
>
> Tangentially related ... When Gump runs (as an agent) it checks it's
> environment (e.g. runs 'env', runs 'java --version', etc.) and captures
> results. This used to be code (incorrectly) located on the Workspace class,
> but I moved it to a separate Environment class. Only today have I restored
> that to the documentation, so watch that space.
>
> regards
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by Nick Chalko <ni...@chalko.com>.
Davanum Srinivas wrote:
>Should we run gump every 6 hours on brutus?
>
>-
>
I do not think we should do this until we are keeping copies of old
builds, so people have time to analyze before they change.
R,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by Nick Chalko <ni...@chalko.com>.
Sam Ruby wrote:
> Adam R. B. Jack wrote:
>
>>> Should we run gump every 6 hours on brutus?
>>
>>
>> Some thoughts I've had...
>>
>> Since we have dedicated cycles, why not do it as soon as the last one
>> stops?
>> What about doing N with --optimise (only build what has changed) and the
>> Nth+1 a full one?
>>
>> BTW: Have a separate 'check metadata' loop (that doesn't build just
>> checks)
>> might be nice for folks committing descriptor changes.
>>
>> I've not written the code (ok, I did, but I ripped it out -- it was
>> inside
>> the engine, not outside) but how about an external script that runs
>> gumpy.py
>> as above [which does CVS update of self in there]?
>
>
> My recommendation is that we first figure out how often we want to
> nag, and work backwards from that.
>
Nag on first failure, and then daily.
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
>>Should we run gump every 6 hours on brutus?
>
> Some thoughts I've had...
>
> Since we have dedicated cycles, why not do it as soon as the last one stops?
> What about doing N with --optimise (only build what has changed) and the
> Nth+1 a full one?
>
> BTW: Have a separate 'check metadata' loop (that doesn't build just checks)
> might be nice for folks committing descriptor changes.
>
> I've not written the code (ok, I did, but I ripped it out -- it was inside
> the engine, not outside) but how about an external script that runs gumpy.py
> as above [which does CVS update of self in there]?
My recommendation is that we first figure out how often we want to nag,
and work backwards from that.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Should we run gump every 6 hours on brutus?
Some thoughts I've had...
Since we have dedicated cycles, why not do it as soon as the last one stops?
What about doing N with --optimise (only build what has changed) and the
Nth+1 a full one?
BTW: Have a separate 'check metadata' loop (that doesn't build just checks)
might be nice for folks committing descriptor changes.
I've not written the code (ok, I did, but I ripped it out -- it was inside
the engine, not outside) but how about an external script that runs gumpy.py
as above [which does CVS update of self in there]?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org