Adam R. B. Jack wrote:

I think we need to ensure we have a 'test' flavour [or test workspace
perhaps] on every box, one that we expect folks to tinker with (when the
main build isn't running). A test workspace would work [other than the
fact
it could mask 'updated'] because we'd only run it at odd times, and we'd
not
crap on the same output tree (like I often do testing.)

Can I suggest a different approach? What I used to do with classic gump was to capture and datestamp the outputs of the "official" runs, keeping a fixed number live. This is a simple matter of copying a few directories at the end of the run.

I've tinkered with this on and off, but not had a separate flag for 'official'. I think it needs to be introduced. (There are mutiple places where we check isFull() [i.e. 'all' projects not some] -- and we have the integrate script different (in what it does) than build or update or debug. There are even comments in the code about 'if official then nag and/or do rss/atom', but much has been removed since I like to test the whole path (quickly) on subsets of a profile.)

This brings me onto configuration, see next...

It appears to me that you are looking at Gump as as monolithic tool. I see it as a series of actions: Generate, Update, Make, Publish...


My suggestion is that we should decompose Gump. There is no reason that everything needs to funnel through a single entry point.

There are a number of discrete actions that users may wish to trigger. These actions may be triggered from the command line, a gui, a webapp, or a cron job.

Focusing initially on the cron job, it needs to run a script. That script can be written entirely in Python (including reading the configuration, setting environment variables, etc). It can do more than what one typically does from the command line (e.g., copying of directories, nagging, etc).

Key points:

1) when it does things typically done by "testing", it calls into the exact same code.

2) official, completed outputs are served from a different URL than incomplete or testing outputs.

3) official runs start by cleaning up the work area. This was done by rsync in "classic" gump.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to