ReleaseEngineering/How To/Land Buildbot Master Changes: Difference between revisions

Updated the instructions on how to land BB master changes
m (→‎Branches: typo)
(Updated the instructions on how to land BB master changes)
Line 35: Line 35:
|}
|}


= How to Land Things, Normally =
= How to Land Things =
This section works on the assumption that you have one or more reviewed and tested patches. When you do, the following procedure should be used to land them:
This section works on the assumption that you have one or more reviewed and tested patches. When you do, the following procedure should be used to land them:
== Land your patches ==
== Land your patches ==
Line 41: Line 41:
<p>This can be done at any time. It does not require you to touch production Buildbot masters.</p>
<p>This can be done at any time. It does not require you to touch production Buildbot masters.</p>


== Watch for errors in Preproduction. ==
== Watch for errors in Travis ==
<p>Our [[ReleaseEngineering/Preproduction|Preproduction systems]] run a variety of tests on landings to the default branches. They will send e-mail if any errors occur. Watch for these and backout or fix your patches appropriately.</p>
Travis CI is a hosted, distributed continuous integration service used to build and test software projects. Whenever we do a push to the above mentioned repositories, there will be some checks that will run against the current code to make sure it's functional. The end result will be displayed in #releng IRC channel. If the checks ran successfully, we can proceed to merging the changes to the production branches, otherwise we'll need to find a fix and repeat this step.
<p>Specifically, look at [http://preproduction-master.build.mozilla.org:8710/one_line_per_build recent builds].


== Merge your changes to the production branch ==
== Merge your changes to the production branch ==
<p>When you are satisfied with the preproduction results and ready to land (ie: do the master reconfigs) you should '''merge''' your changes to the appropriate production branch. When doing so, you should be prepared to take any other tested changes from the default branch, too. See below for some helpful tips on merging.</p>
<p>When Travis is happy with your changes, you should '''merge''' them to the appropriate production branch. When doing so, you should be prepared to take any other tested changes from the default branch, too. See below for some helpful tips on merging.</p>


== Update the Masters ==
== Update the Masters ==
The masters are already set-up to track the production branches of the repositories. After you've pushed your changes to HG you can update the checkouts and reconfig/restart as normal. All masters which track the production branch you've merged must be updated. See [[ReleaseEngineering/Managing_Buildbot_with_Fabric]] for one technique to make this easier.
The masters are already set-up to track the production branches of the repositories. After you've pushed your changes to HG you can update the checkouts and reconfig/restart as normal (the masters automatically reconfig themselves each hour, so, if not urgent, you can wait until then to have the latest changes applied). All masters which track the production branch you've merged must be updated. See [[ReleaseEngineering/Managing_Buildbot_with_Fabric]] for one technique to make this easier.


== Update the Maintenance Page ==
== Update the Maintenance Page ==
Line 73: Line 72:


You can also use "-b" as an argument to "hg out".
You can also use "-b" as an argument to "hg out".
= How to Land High Priority Things =
Sometimes we don't have time to wait for preproduction or don't wish to pull in everything else on the default branch. If you're in a situation like this you can use the following procedure to jump the queue:
* Commit your patch to the production branch '''and the default branch'''.
* Push
* Update the masters
<p>This way, you've landed only your own patch, but still kept 'default' up to date.</p>
<p>Situations that call for this should be very rare.</p>
148

edits