Buildbot

Buildbot is a continuous integration tool. It is used for running automated builds and tests. Mozilla developers can access the results of buildbot jobs through Treeherder and BuildAPI.

Buildbot is being used by Mozilla and other projects, in a number of different ways. This page will serve as the clearinghouse for finding Buildbot-related information. Please try to keep it organized as you add to it.

• Bugs referencing "buildbot"
• Mozilla Buildbot CVS (mxr)
• Updating Buildbot Configuration files

Unit Testing

Unit testing is now done in the same buildbot instance as nightly Builds. There are no specific docs for unittest buildslave setup anymore. Please refer to ReferencePlatforms doc.

Talos (Performance Testing)

• General Info
• Talos CVS (mxr)
• Buildbot Installation, Operation, Development, Issues
• IT Talos Support Document
• Reference Platforms
  • WinXP
  • Vista
  • Mac
  • Linux
• Outage Reports

Build/Release Automation

• Release Automation docs
• Reference Platforms
  • BuildBot
    • Win32
    • MacOSX
    • Linux
  • Buildserver

"Try" Server

• Test patches before checking in
• Try server CVS (mxr)
• Outage Reports
• Maintenance

Mozilla2

• Mozilla2 CVS (mxr)
• Master Setup
• Slave Setup

Axel's Original Buildbot Requirements

A collection of random things that buildbot should do. Please add your item, what it's supposed to do, and an owner, if applicable.

running python on the slave

(Axel) Sample impl should be reviewable soon. Major trick is to add an import of your module to the buildbot start script to hook up the registerSlaveCommand

ensure directory on slave

(Axel) Using the code above

single source checkout per slave

(Axel) This required a blocking scheduler to make all builds run on one source version per slave, together with a lock per slave that notifies the waiting build steps, in this case, to not check out. For multiple check-out targets, this requires the ....

BuildStepGroup

(Axel, help-wanted) This groups a set of steps together, so that they don't loose the lock. I have a somewhat working implementation, but I think that the status reporting is wonky.

Download nightly builds on slave

(nobody) For l10n repackaging, we need to find out when new nightly builds are available, which source time stamp they have, and get them into the right location on the slave.

Compare locales

(Axel) They python implementation can now run natively in the slave, and report a dict object back for rich log parsing on the master, or in a web-facing post processing.