# HG changeset patch # User Jeff Hammel # Date 1343753397 25200 # Node ID c77b946e4496305bea1e48da9ed8dd023d5e0c25 # Parent 8f9862788dce710d304e978e821f6dce9b74b6ed minor fixes to the README diff -r 8f9862788dce -r c77b946e4496 README.txt --- a/README.txt Fri Dec 30 16:27:14 2011 -0800 +++ b/README.txt Tue Jul 31 09:49:57 2012 -0700 @@ -33,14 +33,14 @@ You can create a master-slave pair by running ``create-autobot`` after activating the virtualenv. This is mostly useful for autobot -development. The scripts ``create-autobot-master`` and +development. The scripts ``create-autobot-master`` and ``create-autobot-slave`` are also available and are more useful for production, as normally you will not want to keep the master and the slave on the same machine except for development and testing. The scripts will prompt you for a factory or you can specify one or more from the commandline using ``--factory`` or ``-f``. The factories are from ``autobot.projects`` and its subdirectories. You can list the -available factories with ``create-autobot --list-factories`` (or +available factories with ``create-autobot --list-factories`` (or ``create-autobot-master --list-factories``). Running ``create-autobot --help`` will give the variables you can set @@ -52,11 +52,11 @@ your particular bot. You can change these in the resultant configuration later. - + Using autobot ------------- -The buildmaster and buildslave are started with +The buildmaster and buildslave are started with ``buildbot start master`` and ``buildslave stop slave`` from the bot's directories. Respective ``stop`` commands also exist. If you used the ``create-autobot`` command the generated bot will have a @@ -111,7 +111,7 @@ * pollInterval: how often to poll the repositories, in seconds [DEFAULT: 60] * treeStable: how long to wait before the tree settles down before building [DEFAULT: 60] - + The other defaults may be seen by running ``create-autobot-master --help``. Other parameters given in the ``[:master:]`` section are used as the @@ -128,13 +128,13 @@ * factories: space-separated list of factories to run on that slave. If the special value ``*`` is used, all factories will be run. You - can view the factories available with + can view the factories available with ``create-autobot --list-factories``. The factory name corresponds to the directory (or module) name in ``autobot.projects``. If every slave is meant to run the same factories, you can put this in the ``:master:`` section -* os: the operating system of the slave. Should be one of ``linux``, +* os: the operating system of the slave. Should be one of ``linux``, ``win``, or ``mac`` (though see TODO about future use of MozInfo making this obselescent). You probably *shouldn't* have a default key for this in the ``:master:`` section (though autobot won't try @@ -145,7 +145,7 @@ factory sections: All other sections are used to build the factories. Each parameter in a factory section is used as a constructor (``__init__``) keyword argument when they are created in the -``master.cfg``. So a factory section like:: +``master.cfg``. So a factory section like:: [foo] bar = fleem @@ -168,16 +168,18 @@ What does autobot test? +* mozbase [WORKING] * logparser [WORKING] * profilemanager [IN FLIGHT] * mozmill [IN FLIGHT] * devicemanager [IN FLIGHT] * firebug [TODO] * jetpack [TODO] +* talos [TODO] The projects are obtained from any factories in subdirectories of -``autobot.projects`` (use -``python -c 'from autobot import projects; print projects.__file__'`` +``autobot.projects`` (use +``python -c 'from autobot import projects; print projects.__file__'`` to see this location). @@ -188,7 +190,7 @@ for specifying sources. Sources live as a member on the instance, named (oddly) ``sources``. This is a dict with the key being the source type and the value being the source to use. Source types are -currently "git" and "hg", though this is easily extensible. +currently "git" and "hg", though this is easily extensible. Internally, an individual source is stored as a 2-tuple with the first item being the URL of the source and the second item being the @@ -245,7 +247,7 @@ ``master.cfg`` looks in each factory and gleems its needed repository from its ``sources`` attribute (if any) in the internal storage mechanism of ``SourceFactory`` and sets up schedulers - accordingly. + accordingly. * ``VirtualenvFactory``: inherits from ``SourceFactory``. creates a python virtualenv and provides build properties ``%(virtualenv)s``, @@ -261,8 +263,8 @@ ``%(python)s setup.py install``) * ``FirefoxDownloaderFactory``: downloads and unpacks a Firefox - bundle, using - `GetLatestTinderbox `_ . + bundle, using + `GetLatestTinderbox `_ . It also provides three properties: ``%(firefox_url)s``, ``%(firefox_bundle)s``, and ``%(firefox)s`` -- the last, and most interesting, being the absolute path to the Firefox executable. You @@ -306,6 +308,8 @@ brasstacks test server. you can omit the restserver keyword, it will use the correct default if you skip it +* email notifications + * get FirefoxDownloaderFactory working on Mac with .dmg files! * singular checkout of repos on slaves: the slaves should have a @@ -313,4 +317,4 @@ branch pair. It is then updated as the slaves need and (e.g.) cloned from there. This should effectively minimize fetch time. -* use MozInfo package +* use MozInfo package for slave information