ReleaseEngineering/TryserverAsBranch: Difference between revisions
Lukasblakk (talk | contribs) |
Lukasblakk (talk | contribs) |
||
Line 33: | Line 33: | ||
==Update Cron== | ==Update Cron== | ||
* Make sure that the builds are cleared out properly and frequently since they will take up a lot more space than the old system |
Revision as of 23:34, 13 May 2010
What's this about?
This page documents the moving of tryserver from being on its own master, with separate code from the release automation, to becoming another branch in the configs of the release automation. The main bug 520227 tracks the progress of this endeavor.
The Rollout
Backing up the current setup
The changeset (c7705d122890) of the current buildbotcustom code was tagged to ensure that we could keep that tryserver running at the same time as starting up the new master.
Set up a new master
On pm02, a new master was created with the only active branch being tryserver. Added TRY_SLAVES to config, copied those into c['slaves'] in master-main.cfg Took out slavePortnum and http listening port in master-main.cfg in try-trunk-master
New upload location
Builds & crashreporter-symbols will now be uploaded to ftp.m.o/mozilla.org/firefox/tryserver-builds Symbols for win32 will still go to build.mozilla.org
Dry run with tryserver slaves from production pool
Moving try-w32-slave20, try-linux-slave08, try-mac-slave13 out of sandbox and into build network to test uploads
- Setup for {linux,mac,w32} as per ReferencePlatforms post-cloning steps (production)
- Needed to fix firewall permissions for the slaves to ssh to stage
- Make sure .ssh is 700 and key is 600 in order to connect to stage
- Put in patch to fix tryserver post_upload path/dir to stage instead of build.m.o
Rollout process
- Notify dev-planning, dev-tree-management, blog, put up a notice on MozillaTry tinderbox to let people know there will be longer wait times in the transition period
- Blog/Update docs about how to use push-to-try and the custom mozconfig option
- We will take 1/2 the slaves from the current try master and get them re-imaged and moved to build network
- They will be attached to the new try-as-branch master
- The master will run in parallel with the current try, until green
- Then turn on email notification and switch the tinderbox url to MozillaTry
- At the same time turn off all but mobile on old try
- Re-image the rest of the slaves and put in build network
Update Nagios
Will need to use start_buildbot.sh, so adjust nagios accordingly to watch for 2 twistd procs.
Update Cron
- Make sure that the builds are cleared out properly and frequently since they will take up a lot more space than the old system