ReleaseEngineering/TryserverAsBranch: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
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