Workflow model GM AR Gumpy RM Dyagump At a very high level, this is what gump does. We ll be lookig at each of the items described here seperately. User edits project descriptor ad commits s maitai their ow descriptors (based o the GOM or maves POM) The Gump Metadata (GM) is built from those GOMs ad POMS (as a RDBMS, potetially) Gump checks out or updates stuff ad rus build scripts Gump seds certai output ito the artifact repository Gump seds build results ad iformatio ito the Rutime Metadata (RDBMS with history iformatio) Dyagump seds e-mails ad the like based o that Dyagump geerates user reports o demad
<workspace> <module> <sv /> <project ame= myproject > <at target= jar /> <jar ame= build/myproject.jar /> <deped ame= otherproject /> </project> </module> <module href= project/other.xml > </workspace> XML files. Most live i Gump CVS (will live i Gump SVN). Similar to mave project.xml files Ca split up ito multiple files (across repositories) usig hrefs <module/> for each CVS or SVN module <project/>, usually for each uit that produces somethig (ie a jar file), may also ru tests or geerate docs or s declare iputs (depedecies), outputs, ad build commads (<at/>, <mave/>, <mkdir/> ) See http://gump.apache.org/metadata/, actually a lot of docs o these Lear by example look at setups for other projects TODO: We wat to make gump read mave project.xml files 2
GM Metadata Workspace Module Module Module Gumpy builds a object graph i memory (gump.model package) which cotais all the gump itelligece regardig the model, for example, it will fill out the model with defaults if some elemets are omitted, ad trasform the way depedecies are specified ito a stadard way. It is a bit of a shame that most of what goes o here is ot documeted. Rather, the assumptios made here ca oly be retrieved from seeig how the actual XML descriptors we use actually lead up to somethig. Fortuately for ed users, you ever eed to see most of this. 3
AR Artifact Repository myproject.jar Gumpy maitais a repository of all the stuff that it has built. But we cosider it iteral-use oly: because Gump is iheretly usecure (we dowload arbitrary code from arbitrary CVS that ca execute arbitrary commads), these files could cotais bugs or eve viruses! 4
Gumpy Gumpy <<rus>> Builder 4 <<rus>> <<starts>> Ruer CLI Actor 5 <<updates>> Checkouts <<reads>> Updater Loader 2 3 <<creates>> <<creates>> Ru <<rus>> Actor Actor Workspace GM Module Module Module <<reads,aotates>> <<rus>> <<iteracts>> SVN,CMS, Files, Mailig lists, Database, Website, Gumpy is our buildmeister, a object-orieted pytho egie which hadles all differet kids of tasks, which we split up ito bits called Work. These Work items are hadled by either a core compoet (Ruer, Loader, Updater or Builder) or by a Actor (documeter, otifier, ad others). The workflow is as follows: A commad is started from a crojob This commad does a self-update, iitializatio, parses optios, sets up loggig, etc Now, a Ruer is created, which cotais most of the core build logic It delegates to the Loader to build a Gump Object Model i memory from the xml descriptors Next it fires up the Update which checks out or updates materials from versio cotrol It is ow time to start doig real thigs. The mai task is buildig all the differet projects, which the Builder hadles. The ruer also refereces several Actors, which ca cause side effects, like sedig out e-mail. TODOs: It would probably be better to make Builder, Updater ad perhaps 5
RM time-ivariat Rutime Metadata (RM) eviromet Host Ru address properties uri timestamp uri ame Package Workspace depedecies Result success failure halt Build uri log _versio timestamp Module url descriptor uri descriptor The RM database is the basis for most of gump s itelliget behaviour. By careful aalysis of the data i this database, we ca figure out who caused what to break whe, which projects are logterm problematic, etc etc. The RM database is differet from what happes before it (ie the stuff that Gumpy does) i that it models time. Gumpy simply rus several times a day ad publishes the result of each ru, but it does t try ad compare those rus to each other. Istead, Gumpy pushes data ito the RM so that Dyagump ca do that aalysis. Hosts are idetifiers for physical machies; besides a address (ie brutus.apache.org) they have certai ifo about it, like the # ad type of cpu. Workspaces are gump rus cofigured with some particular set of parameters that might ifluece the way it builds (like the live build or the kaffe build o a machie). Decisios which chage over time (by a gump admi chagig somethig) are i the workspace rather tha directly with the host. Rus are the complete sets of results for ay particular gump ru. They specify what istalled packages (for example java versio or kerel versio) was built agaist, ie the etire eviromet, as well as all the builds that were ru. Thigs which chage over time (out of the gump admi s direct cocious cotrol) are part of a ru rather tha the workspace. 6
Dyagump I do t really get it! Could you make gump easier to use? Ad make it a little prettier as well? DyaGump is curretly uder developmet. We do t kow exactly what it will look like (Shiy! Sweet! Cool!) ad its featureset is still beig thought about. The key thig we wat to do here is make gump easier to use. Better reportig, friedlier e-mails, etc etc. Watch this space! 7