ReleaseEngineering/How To/Land Buildbot Master Changes

This page is intended to aid you in understanding the repositories related to Mozilla Corporation Buildbot Masters and how to successfully apply patches to them.

Repositories

• buildbot - This repository is our local copy of the upstream Buildbot code. It contains imports of upstream releases and often patches that have not made it into an official Buildbot release. Our Buildbot masters and slaves use an installed version of the code from this repository.
• buildbotcustom - This repository contains many custom Factorys, Steps, Schedulers, and other non-upstreamable Buildbot code. It generally contains code that is or can be shared between Buildbot masters.
• tools - Our Buildbot masters also use some library functions from the build/tools Python library. Generally, this is code that is used by both Buildbot Masters as well as client-side scripts or other, non-Buildbot tools.
• buildbot-configs - This repository contains Buildbot master configuration, including most branch specific things, mozconfigs, and other configuration details.

Branches

Some of the aforementioned repositories are managed with different in-repo, named branches. The table below should serve as a guide to understanding them:

Repository	Branch	Description
buildbot buildbotcustom	default	This branch is the first point of landing for any Buildbot changes targeting the 0.8.x masters.
	production-0.8	0.8.x Buildbot masters track this branch. Changes should not be merged to it until you are about to update the affected masters.
	buildbot-0.7	This branch is the first point of landing for any Buildbot changes targeting the 0.7.x masters.
	production-0.7	0.7.x Buildbot masters track this branch. Changes should not be merged to it until you are about to update the affected masters.
buildbot-configs	default	This branch is the first point of landing for any Buildbot changes targeting any masters.
	production	All Buildbot masters (regardless of Buildbot version) track this branch. Changes shuold not be merged to it until you are about to update all affected masters.
tools	default	Currently, this is the only used branch of the tools repository. It should be treated like the "production" branches of other repositories.

How to Land Things

This section works on the assumption that you have one or more reviewed and tested patches. When you do, the following procedure should be used to land them:

Land your patches

Land your patches on the appropriate "default" branch. For 0.8 masters this is always 'default'. For 0.7 masters it may be 'buildbot-0.7'.

This can be done at any time. It does not require you to touch production Buildbot masters.

Watch for errors in Preproduction.

Our Preproduction systems run a variety of tests on landings to the default branches. They will send e-mail if any errors occur. Watch for these and backout or fix your patches appropriately.

Merge your changes to the production branch

When your satisfied with the preproduction results and ready to land you should merge your changes to appropriate production branch. When doing so, you should generally be prepared to take any other tested changes from the default branch, too. See below for some helpful tips on merging.

Merging Tips

Previewing a Merge

To see which changesets will be merged without affecting your local repository, update to the production branch you plan to update, and run "hg merge -P". For example, to preview a merge from the 0.8 default branch in buildbotcustom, do the following:

hg up -r production-0.8
hg merge -P default

To preview a merge in the same repository, but on 0.7, do the following:

hg up -r production-0.7
hg merge -P buildbot-0.7

Merging

To perform the merge, use the same merge command as above, without "-P". For example:

hg up -r production-0.8
hg merge default

You will need to commit this merge. It's advisable to include a summary of what's been merged in the commit message. For example:

hg commit -m "Merge bugs 616320, 616583, and 615097 from default branch"