Skip to end of metadata
Go to start of metadata

This object digram describes in coarse detail how some of the core objects relate to each other. It describes how a build process starts by first checking out, determining if there are any changes, and then possibly executing a build. The steps are as follows:

1: A checkout is requested.

There are two different situations that will result in a build to be executed. They both start with the blue objects:

  • A build is trigged (step 0). This can be done via the web interface or over XML-RPC. Typical XML-RPC invocations come from either a trigger in the SCM (if it is installed), or via some other external program using the XML-RPC interface.
  • The SCMPoller decides it is time to poll a project and see if there are any changes.

2: The SCM checks out latest

The CheckoutManager asks the SCM to check out the latest code. This call will return a ChangeSets object which contains detailed information of what was checked out (and maybe even deleted) since the last checkout. It then finds most recent timestamp of all the changes in the ChangeSets and saves that timestamp in the project configuration (to be used in the future).

(For practical reasons, if the checkout is a first-time checkout, the SCM will return the timestamp of the most recent checkin rather than all the changesets. This is to avoid having a too big list of changes in the first build report).

3: A build is requested

A build object is created (which holds the changesets), and the execution of that build is requested within the BuildScheduler. Special note for SCMPoller: This will only happen if there were changes. If there were no changes as the result of the checkout, no request will be made with the BuildScheduler.

4: A build is executed

When a BuildExecutor becomes available (there may be several of them, depending on how you have configured DamageControl), the scheduled build will be given to it. The BuildExecutor will execute the build, and finally send an event on the hub when the build is finished (whether it succeeded or not). This event will then be picked up by other components, which may perform various notification tasks (email, irc, etc.)

  • No labels