Bamboo's Build Process

A Chain (what users see as a Plan in the UI) consists of one or more Stages and each Stage consists of one or more Jobs.  Before progressing to the next Stage, every Job in the previous Stage must have completed successfully.  There is no order to Jobs within a Stage so when a Stage is executed, all Jobs in that Stage are placed in the queue immediately.

All triggering strategies now work at the Chain level.  Chains do not take Job information into account when deciding whether to trigger.  If repository polling or repository trigger strategies are selected, only changes detected against the Chain's are used to determine if the build will be triggered. 

Below is a diagram which shows Bamboo's build process flow, as well as the available plugin modules you can build.

Build Process For Chain

Build Process Per Job

Further Notes

1. Build is Triggered — Changes are detected via polling (against the Chain's repository configuration only), manual builds, etc.
2. Preperation for Build — The Build Number is determined then ResultsSummary objects and BuildContexts are created for the Chain and every Job within the Chain. The build number information, latest revision keys and ResultSummaries are persisted to the database.
3. Job Queued — The server decides which agents can execute the job and queues the job.
4. Agent Picks Up Job — The capability context is set. The job is removed from queue. The agent begins looping through the build tasks.
5. Retrieve Source — The agent runs the CheckoutUpdateForBuild task. The Repository#retrieveSourceCode is called. If the Repository is RepositoryEventAware the appropriate methods will be called. The agent checks if the repository has changed since the last build and clears the source directory if it has.
6. Prepare Job — The agent runs the PrepareBuildTask. This begins streaming the logs back to the server. The agent also runs the CustomPreBuildAction plugin point.
7. Executes the Job — Timer begins. The agent runs the Builder#executeBuild. The CommandDecorator plugin will be run against the command line just before execution. After the Builder has been run, all the CustomBuildProcessors are run. Timer is stopped.
8. Process Job Result — The server runs CustomBuildProcessorServer, checks if the job has passed and saves and indexes the result. The server also fires off the BuildCompletedEvent and PostBuildCompletedEvent events, and executes any CustomPostBuildCompletedActions.
9. On BuildCompletedEvent (performed by the server) — Notifications are sent in this phase.