gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Davey <Michael.Da...@coderage.org>
Subject [RT] Gump service (was: brutus)
Date Tue, 08 Jun 2004 07:28:57 GMT
Adam R. B. Jack wrote:

>
>4) Figuring out a way (some service?) to have a continuous Gump. The "gump
>every three hours" line in crontab is a waste of two hours when builds take
>4 hours. I'd like some sort of 'permanent restart' loop.
>  
>
I keep thinking about this (especially as one of my private gumps 
usually takes 25 hours to run).  The absolute simplest way would be to 
simpy have a bash script that calls gumpy.py in an infinate while loop.  
However, I think this would be a very good time to refactor gump into a 
workflow.

Server component to look at the projects and work out which ones Gump 
needs to try to build next.  To start off, the algorithm stays as it is 
now.  In future we can look to detect if there have been CVS commits 
since last build and so on.  Server component puts "n" work pieces into 
a pool.

Service/Client component takes one project out of the pool, performs cvs 
update and attempts to build (again using the current algorithm).  Puts 
the results into a second pool.

View component takes the results from the second pool and produces the 
web site.  Alternatively, the second pool could be replaced with a 
filestore and the view generates the pages on the fly from the 
filestore.  The view component is forrest with a little glue logic.

The nice thing about this is that it opens up many more possibilities 
for the future.  For instance, it would enable distributed gump at the 
client component.

-- 
Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message