GBuild Agent Overview
We've taken Continuum, ActiveMQ, and a whole lot of long nights and days and created a system that can push continuum builds onto a jms queue (activemq) where are then picked up by GBuild Agents (slimmed and extended version of continuum) running in the gbuild network. The results are then pushed onto a jms topic where and aggregted by another agent in the gbuild network. Putting more work on the queue is as easy as dropping a properties file in a directory.
A really cool aspect of this is that we can throw more machines at it in the middle of a run. It's just jms queue/consumer underneath so new consumers can be added at anytime! The whole thing is very extendible and not specific to tck testing, so we could work in performance testing and whip up results agents to analyze the performance data. Sky is the limit!
We tried to reuse Continuum as as much of this code as possible is destined to them. The idea is that we only should need to maintain a few extensions for the things that are specific to us or they don't want.
Executing Agent (runs builds)
Each agent consumes or produces on a queue or topic (or both). You can have as many of each as you need or what. They can run in the same process or separate processes. All messages are Maps that are serialized to ObjectMessages onto either the BUILD.TASKS queue or the BUILD.RESULTS topic.
Runs continuums various continuum componentry and "update-from-scm" and "execute-builder" actions. When this is done, the code has been updated and built. Has extendible pre and post checking of incoming builds and outgoing build results. Specifically there is a BuildAgentExtension (when spelling is fixed) that has a pre(Map incoming) method and a post(Map incoming, Map outgoing) method.
Implemented Extensions so far:
Scans a directory for properties files that define builds to add to the build queue. This part could use some work. The implementation that uses properties files is fine for shoving lots of work onto a queue in a really easy way, but this is where we also need some more integration with continuum as a frontend. An implementation of A Producing Agent could be an alternate implementation of the Continuum build queue that just turns the build tasks into items that go onto the jms build queue. Once you do something like that, you need to consider how things work in Continuum in regards to it's single threaded nature that seems to be assumed in places of the code.
Very bare bones agent that consumes from teh BUILD.RESULTS topic and invokes BuildResultsExtensions (when spelling is fixed). Performs no other work aside from invoking the extensions. We can really go nuts with extensions here. No limit to the ones we can creat to log, track, compile, report, analyze or otherwise process the results data in various ways.
The only BuildResultsExtension so far is one that scans for entries in the results map matching a regex ("^include.*" is the standard). It takes the value of that entry and writes it into a file. The name of the file can be created using entries in the map as well. So for example: