ReleaseEngineering/How To/Stage Work on Staging Master
This page describes the best practices for using staging-master. In particular, the moz2-master and moz2-master2 instances on it.
Contents
First run stuff
If you've never used one of the staging masters before you'll need to ensure you have clones of the repositories before the instructions below will work. To do so, do the following;
cd /builds/buildbot/user-configs hg clone http://hg.mozilla.org/build/buildbot-configs $username-configs cd ../user-configs2 hg clone http://hg.mozilla.org/build/buildbot-configs $username-configs cd /tools/buildbotcustom hg clone http://hg.mozilla.org/build/buildbotcustom buildbotcustom-$username cd ../buildbotcustom2 hg clone http://hg.mozilla.org/build/buildbotcustom buildbotcustom-$username
Scheduler DB masters
The scheduler db masters currently run out of the 'default' branch in both buildbotcustom and buildbot-configs. The 'update-configs.sh' script in the relevant master directory will update the checkout to the appropriate branch.
scheduler_master
This is the main staging scheduler master. It is responsible for all the hg polling and receiving and acting on sendchanges. There's no web interface since all it has is schedulers and change sources. It writes new changes, buildrequests, etc. to a remote mysql database that is used by builder_master1.
builder_master1
This is the main buildbot master on this machine. It uses a remote mysql database to fetch build requests from.
hg polling and creation of most new jobs is handled by scheduler_master
To work on this master, check out 'sm01' in the bookings page, and make sure moz2-master is stopped, then do the following:
# cltbld@staging-master cd /builds/buildbot/builder_master1 ./switch_configs.sh $name
When starting, stopping, etc. you should use the Makefile targets to ensure PYTHONPATH is correctly set. For example:
# cltbld@staging-master cd /builds/buildbot/builder_master1 make stop make checkconfig make start
builder_master2
This is a secondary buildbot master on this machine. It handles both scheduling and building, and uses a local sqlite database.
To work on this master, check out 'sm02' in the bookings page, and make sure moz2-master2 is stopped, then do the following:
# cltbld@staging-master cd /builds/buildbot/builder_master2 ./switch_configs.sh $name
When starting, stopping, etc. you should use the Makefile targets to ensure PYTHONPATH is correctly set. For example:
# cltbld@staging-master cd /builds/buildbot/builder_master2 make stop make checkconfig make start
Old masters
moz2-master
This used to be the main Buildbot master on this machine. It normally has 3 slaves per platform connected to it, and constantly runs builds. To swap in your Buildbot configs for this master do the following:
# cltbld@staging-master cd /builds/buildbot/moz2-master ./switch_configs.sh $name
...and apply local changes.
When starting, stopping, etc. you should use the Makefile targets to ensure PYTHONPATH is correctly set. For example:
# cltbld@staging-master cd /builds/buildbot/moz2-master make stop make checkconfig make start
moz2-master2
This is a secondary Buildbot master and only used when two people want to test things at the same time. It normally has no slaves attached to it. If you are using it you may pull slave(s) from moz2-master, after checking with the person who is already using it. Please make sure to return them to moz2-master when you're doing with them. To swap in your Buildbot configs for this master do the following:
# cltbld@staging-master cd /builds/buildbot/moz2-master2 ./switch_configs.sh $name
When starting, stopping, etc. you should use the Makefile targets to ensure PYTHONPATH is correctly set. For example:
# cltbld@staging-master cd /builds/buildbot/moz2-master2 make stop make checkconfig make start
Cleanup after yourself
When you're done with either master please make sure to swap back in the clean configuration files using switch_configs.sh in the appropriate directory, like this:
cd /builds/buildbot/moz2-master switch_configs.sh clean