ReferencePlatforms/How To/Setup a New Reference Platform: Difference between revisions

If the answer is no to any of the questions above, you'll need to setup a new master, unless there unused masters that are already provisioned and available to you.  Open a bug with IT to bring up some VMs where you can install a new master (example: {{bug|782870}}.  Read [[ReleaseEngineering/Master_Setup]] to understand the steps to setup a new master.  This document also describes some bugs that need to be opened with various teams when setting up the new master, so read it now.

This is a example {{bug|783455}}.  The  buildmaster-production.pp  (puppet-manifests) needs to have the new masters added to the nodes so you can puppetize the new masters.  The productionmasters.json (tools) needs to have the new masters listed.  I initially set them to disabled, they will be enabled when we are ready for production.  Before the reconfig to enable the new master occurs, you should add ssh keys and an updated authorized_keys file to the master.  Once the reconfig is complete, you'll need to start the new master.

 

 

There are also changed required to enable a platform's tests running to mozilla-central + peers see https://bugzilla.mozilla.org/show_bug.cgi?id=777759#c31 for an example.  

The changes in puppet-manifests repo are changes to the modules/buildmaster/templates/BuildSlaves-tests.py.erb file.  (From rail: the BuildSlaves-tests.py.erb file is in the puppet-manifests repo, but these machines are running from puppet again master).  As well, you'll need to update the secrets.pp.template and secrets.pp on master-puppet1, and replicate these changes to the other masters.  Changes to the puppet-again servers are deployed automatically, changes to the puppet-manifests servers are not. See [[ReleaseEngineering/Puppet/Usage#Deploy_changes]] on how to deploy changes to servers pulling from the old puppet-manifests repo.

** need to land changes to 'sql/data.sql' on the default branch of http://hg.mozilla.org/graphs (to match your inserts).

** If this is a new build platform, make sure that graph server knows about the build platform

*** insert a machine name like %OS%_%branch% (e.g. "WINNT_5.2_mozilla-central" and "WINNT_5.2_mozilla-central_leak_test")

 

We don't have access to update the graph server anymore. You need to open a bug with the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Data%20%26%20BI%20Services%20Team&component=Database%20Operations database operations team] to add them. This is an example {{bug||1131072}} of such a request.

== Open a bug for Treeherder changes ==

== Open a bug for buildfaster changes ==

        ('winxp', ['Rev3 WINNT 5.1']),

+        ('win8', ['Rev3 WINNT 6.2']),

== Slave health ==

== Disable tests on branches where this platform isn't needed ==

** {{bug|786424}} shows an example, disabled Mountain Lion tests for mozilla-esr10

** {{bug|803248}} buildbot config changes to support panda_android*

When testing, ensure that you initiate sendchanges to both the the superset of branches, and the branches you want to limit the tests on to ensure when you run it in production there aren't any unexpected builds.

* Add the new slaves to slavealloc (initially disabled)

*** to enable the new masters in productionmasters.json see {{bug|783455}}

 

  (perhaps this should be moved to another section or document)