A day in the life of the buildbot:
Changes towards the buildmaster). The
Changecontains information about who made the change, what files were modified, which revision contains the change, and any checkin comments.
importantchanges cause the
tree-stable-timerto be started, and the
Changeis added to a list of those that will go into a new
Build. When the timer expires, a
Buildis started on each of a set of configured Builders, all compiling/testing the same source code. Unless configured otherwise, all
Builds run in parallel on the various workers.
Buildconsists of a series of
Stepcauses some number of commands to be invoked on the remote worker associated with that
Builder. The first step is almost always to perform a checkout of the appropriate revision from the same VC system that produced the
Change. The rest generally perform a compile and run unit tests. As each
Stepruns, the worker reports back command output and return status to the buildmaster.
Buildruns, status messages like “Build Started”, “Step Started”, “Build Finished”, etc, are published to a collection of Status Targets. One of these targets is usually the HTML
Waterfalldisplay, which shows a chronological list of events, and summarizes the results of the most recent build at the top of each column. Developers can periodically check this page to see how their changes have fared. If they see red, they know that they’ve made a mistake and need to fix it. If they see green, they know that they’ve done their duty and don’t need to worry about their change breaking anything.
MailNotifierstatus target is active, the completion of a build will cause email to be sent to any developers whose
Changes were incorporated into this
MailNotifiercan be configured to only send mail upon failing builds, or for builds which have just transitioned from passing to failing. Other status targets can provide similar real-time notification via different communication channels, like IRC.