canmove, Confirmed users
6,441
edits
ReleaseEngineering/Buildbot Best Practices: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/Buildbot Best Practices (view source)
Revision as of 15:15, 12 March 2009
, 12 March 2009no edit summary
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
* [http://hg.mozilla.org/build/buildbotcustom/ buildbotcustom] - This repository contains custom steps, factories, and other Mozilla specific Buildbot code required by our Buildbot masters. | * [http://hg.mozilla.org/build/buildbotcustom/ buildbotcustom] - This repository contains custom steps, factories, and other Mozilla specific Buildbot code required by our Buildbot masters. | ||
* [http://hg.mozilla.org/build/buildbot/ buildbot] - This repository is an import of upstream Buildbot code, plus some patches that we require. | * [http://hg.mozilla.org/build/buildbot/ buildbot] - This repository is an import of upstream Buildbot code, plus some patches that we require. | ||
== Check-in Policies == | |||
* We track configuration updates to our masters on [[ReleaseEngineering:BuildbotMasterChanges BuildbotMasterChanges]]. Any change to a production Buildbot Master should be tracked on this page. | |||
* Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | |||
* Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | |||
== How to land a patch == | |||
Below is one way to land a patch for a Buildbot master. Your technique may vary, but this will ensure there are no other patches sneaking in with yours, and no local changes. Before doing any of the below, land your patches into the repositories. | |||
* Look for local changes on the master. | |||
cd /tools/buildbotcustom/buildbotcustom | |||
hg diff | |||
cd /builds/buildbot/configs | |||
hg diff | |||
* Check to make sure only your patches are going to be enabled | |||
cd /tools/buildbotcustom/buildbotcustom | |||
hg in | |||
# If there are more than just your changeset use 'hg in -p' to look at the diffs | |||
hg in -p | |||
# Same thing for configs | |||
cd /builds/buildbot/configs | |||
hg in | |||
hg in -p | |||
* Now, assuming there are no interfering patches, pull the changes for real | |||
cd /tools/buildbotcustom/buildbotcustom | |||
hg pull && hg up | |||
cd /builds/buildbot/configs | |||
hg pull && hg up | |||
* Run checkconfig to make sure the reconfig/restart will succeed | |||
cd /builds/buildbot/$master | |||
buildbot checkconfig | |||
* If everything looks OK, reconfig or restart the master | |||
buildbot reconfig . | |||
# OR | |||
buildbot restart . | |||