Adam R. B. Jack wrote:
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.
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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
