webrtc_m130/tools/continuous_build
kjellander@webrtc.org fe87f8ce08 Libvpx buildbot waterfall.
I think I found a decent way to avoid duplicating the whole configuration for the libvpx waterfall. It's not perfect but it works. I still haven't figured out what the best way to manage the slaves would be however, since they will need to know which master to connect to, or they'll pick the default they're configured for in slaves.cfg, which is the WebRTC waterfall (can be overridden with the TESTING_MASTER property, but that's only to be used for development and testing.

BUG=None
TEST=Tested on local master and slaves.

Review URL: https://webrtc-codereview.appspot.com/595005

git-svn-id: http://webrtc.googlecode.com/svn/trunk@2310 4adac7df-926f-26a2-2b94-8c16560cd09d
2012-05-29 06:23:42 +00:00
..
2012-05-29 06:23:42 +00:00

WebRTC buildbots
================
These buildbot setups are based on how Chromium uses Buildbot scripts with their
own customizations of startup and master-slave configurations.

The directory layout and the files inside build_internal/masters are copied from
Chromium's repository and modified for our needs according to the guidelines at
http://goo.gl/kPSSv

One nice advantage with using this, is that all slaves run out of the box by
just syncing the WebRTC tools and the third-party dependencies. No additional
dependencies are required except a Python install.


Setup a tools workspace:
========================
mkdir webrtc-tools
cd webrtc-tools
gclient config http://webrtc.googlecode.com/svn/trunk/tools
gclient sync
cd tools/continuous_build
svn co http://src.chromium.org/svn/trunk/tools/depot_tools
echo pass > build/site_config/.bot_password


To run the build master:
========================
cd tools/continuous_build/build_internal/masters/master.webrtc
make restart


To run the try master:
======================
cd tools/continuous_build/build_internal/masters/master.tryserver.webrtc
make restart


To run a slave:
===============
cd tools/continuous_build/build/slave

There are some variables that can be set for flexible development testing:
* TESTING_SLAVENAME         : Simulates the slave name. Since slave names are
                              based on hostnames, they must be overridden using
                              the this variable in order to run the slave on the
                              local machine.
* TESTING_MASTER            : The master to connect to. We usually use 'WebRTC'
                              or 'TryServer'.
* TESTING_MASTER_HOST       : The host the master is located at.
                              Default: localhost
* RUN_SLAVE_UPDATED_SCRIPTS : Set this to False to avoid checking for updates
                              during startup.

For Windows, make sure to add the --use_buildbot_8 flag to the run_slave.bat
in order to make the tests execute properly.

Examples:
---------

Connect to a running build master:
* Linux and Mac:
TESTING_SLAVENAME=webrtc-cb-linux-slave-1 TESTING_MASTER=WebRTC make restart

* Windows:
set TESTING_SLAVENAME=webrtc-cb-linux-slave-1
set TESTING_MASTER=WebRTC
run_slave.bat --use_buildbot_8

Connect to a running try master:
* Linux and Mac:
TESTING_SLAVENAME=linux-trybot-1 TESTING_MASTER=TryServer make restart

* Windows:
set TESTING_SLAVENAME=linux-trybot-1
set TESTING_MASTER=TryServer
run_slave.bat --use_buildbot_8