autobot
=======

buildbot for the A*Team


What is autobot?
----------------

autobot is a continuous integration solution for the Automation and
Tools Team.  We have a lot of software.  We're really talented, so
usually it doesn't break.  But we're not infalliable.  Our robot ally,
autobot, is there to test things for us.  Let's me autobot!


Installing autobot
------------------

autobot may be installed using the Install script::

 curl http://k0s.org/mozilla/hg/autobot/raw-file/tip/INSTALL.sh | bash

This will create a virtualenv and install autobot for development
($VIRTUAL_ENV/src/autobot). 


Setting up a buildmaster and slave
----------------------------------

Once you have autobot installed and the virtualenv activated, you'll
want to create a buildmaster and a buildslave.

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 
``create-autobot-slave`` are also available.  The scripts will prompt you
for a factory. The factories are from ``autobot.projects`` and its
subdirectories.  You can list the available factories with
``create-autobot --list-factories`` (or ``create-autobot-master
--list-factories``).

Running ``create-autobot --help`` will give the variables you can set
when it makes a new bot for you (``create-autobot-master`` and
``create-autobot-slave`` also have a ``--help``, the variables in
``create-autobot`` being a superset of these).

If you don't specify a variable, the default will be used to create
your particular bot.  You can (probably) change it later.

 
Using autobot
-------------

The buildmaster and buildslave are started with 
``buildbot start master`` and ``buildslave stop slave``. Respective
``stop`` commands also exist.  If you used the ``create-autobot``
command the generated bot will have a ``restart_buildbot.py`` script
that will stop and start both the master and slave and (if debug is
set) remove the log as well.

The generated ``master.cfg`` file reads values from an ``master.ini``
file in the same directory

It is important to remember that continuous integration is a safety
net, not a first line of defense.  


Projects
--------

What does autobot test?

* logparser      [WORKING]
* profilemanager [IN FLIGHT]
* mozmill        [IN FLIGHT]
* devicemanager  [IN FLIGHT]
* firebug        [TODO]
* jetpack        [TODO]

The projects are obtained from any factories in subdirectories of
``autobot.projects`` (use 
``python -c 'from autobot import projects; print projects.__file__'`` 
to see this location).


Adding a New Project
--------------------

Occassionally, you'll need to add a new project to test.  You can add
a ``__init__.py`` file


Is your autobot being feisty?
-----------------------------

Let me know! I'd like to make autobot a solution that works for all
stake-holders, and if you're reading this, that means you!

jhammel@mozilla.com

TODO
----

No software of any size is ever finished.  Here are a few things I
would like to add:

* singular checkout of repos on slaves: the slaves should have a
  singular master repo that is checked out once for each repo URL,
  branch pair.  It is then updated as the slaves need and (e.g.)
  cloned from there.  This should effectively minimize fetch time.

* slaves should have .ini files indicated by the config