The GBuild Agents collectively use the following JMS Topics and Queues. All the names are configurable if you wished to use the same components several times on the same broker with slightly different purposes, this could be configured in the application.xml file of the Agent.
The BUILD.TASKS queue
This is the primary queue that all the build agents pull from. Each message sent to this queue is a javax.jms.ObjectMessage holding a serialized HashMap instance. This HashMap contains the following entries. The keys in this map are also referred to as headers.
store |
an instance of ContinuumStore that basically just holds the Project and BuildDefinition instances needed to run the build |
project.name |
a string representing the name of the project. I've typically been using the maven artifactId as the project.name |
project.version |
the version of the project |
projectId |
a java.lang.Integer which is the id of the project as it is in the ContinuumStore |
project-id |
an alias for projectId |
project.id |
an alias for projectId (i like the dots) |
build.name |
a simple java.lang.String token (i.e. no spaces all filename safe characters) which will be a unique name for the build definition |
buildDefinitionId |
a java.lang.Integer which is the id of the BuildDefinition in the ContinuumStore |
build-definition-id |
alias for buildDefinitionId |
build-id |
the java.lang.Integer that should be used as the BuildResult id, currently just set to the buildDefinitionId cause we don't yet track the builds aggressively |
build.id |
same as build-id |
include.<foo> |
special headers used by the FileIncludeExtension to read any file from the project and include it's contents as a string in the result message. Any number of these headers can be added. |
header.<foo> |
Just a generic bucket used for adding any kind of metadata to the message. The header will be found by the HeaderIncludeExtension and copied as is to the result message. Useful for when the agent producing the build and placing it on the queue wants some data about the build sent back to it when with the results. This could perhaps be a session id or some other info that helps the build producer aggregate or track results. |
The BUILD.RESULTS topic
The results from a build agent that pulled work from the BUILD.TASKS queue are sent to this topic. This is the rally-point for all the agents in the network. Agents "listening" on the BUILD.RESULTS topic can process things in any number of ways, including to writing data to a database, doing analysis of failures and performance over a period of time, specific kinds of reporting, etc.
Each message sent to this topic is a javax.jms.ObjectMessage holding a serialized HashMap instance. This HashMap contains the following entries. The keys in this map are also referred to as headers.
store |
an instance of ContinuumStore that basically just holds the Project and BuildDefinition instances needed to run the build |
project.name |
a string representing the name of the project. I've typically been using the maven artifactId as the project.name |
project.version |
the version of the project |
projectId |
a java.lang.Integer which is the id of the project as it is in the ContinuumStore |
project-id |
an alias for projectId |
project.id |
an alias for projectId (i like the dots) |
build.name |
a simple java.lang.String token (i.e. no spaces all filename safe characters) which will be a unique name for the build definition |
buildDefinitionId |
a java.lang.Integer which is the id of the BuildDefinition in the ContinuumStore |
build-definition-id |
alias for buildDefinitionId |
build-id |
the java.lang.Integer that should be used as the BuildResult id, currently just set to the buildDefinitionId cause we don't yet track the builds aggressively |
build.id |
same as build-id |
os.name |
The Operating System name from System.getProperties |
os.name |
The Operating System version from System.getProperties |
java.vendor |
The Java Vendor name from System.getProperties |
java.version |
The Java Version number from System.getProperties |
host-name |
The host name of the agent as reported by InetAddress.getLocalHost() |
host-address |
The host address of the agent as reported by InetAddress.getLocalHost() |
contributor |
The organization name of the company or person hosting the agent. Configured in the application.xml |
admin-address |
The the admin to contact with any questions or issues regarding the agent. Configured in the application.xml |
build.output-file.gz |
The console output from the build task ran by the build agent. The content is an array of GZipped bytes. |
include.<foo> |
The contents of any files added by the FileIncludeExtension. These will be written to disk by the WriteIncludeFileExtension BuildResultsExtention. |
header.<foo> |
Any headers included in the original build task message that were echoed back by the HeaderIncludeExtension |
The BUILD.ACTIVITY topic
The build activity topic is more or less a way for Agents to do logging in the GBuild network. Each message sent to this topic is a javax.jms.ObjectMessage holding a serialized HashMap instance.
notification |
A string with some logging-oriented information sent by an Agent in the GBuild Network |
os.name |
The Operating System name from System.getProperties |
os.name |
The Operating System version from System.getProperties |
java.vendor |
The Java Vendor name from System.getProperties |
java.version |
The Java Version number from System.getProperties |
host-name |
The host name of the agent as reported by InetAddress.getLocalHost() |
host-address |
The host address of the agent as reported by InetAddress.getLocalHost() |
The BUILD.PING topic
This topic is used by Agents to send "ping" messages of type javax.jms.TestMessages containing the string value of System.currentTimeMillis().
The ping messages serve a few purposes
- It helps to keep the connection alive on networks that automatically close connections it sees as inactive.
- It allows one to easily see which agents are active in the build network.
The BUILD.NOTIFICATIONS topic
Ok, so this one hasn't been created yet, but it will be the future topic used to support Continuum Notifications (IRC, EMAIL, etc.) on continuum defined build events. Have any spare time to write it?