Merge branch 'buildbot-0.8.7'

master/MANIFEST.in

@@ -16,7 +16,7 @@ include docs/manual/_images/*.txt
 include docs/manual/_images/*.ai
 include docs/manual/_images/icon.blend
 include docs/manual/_images/Makefile
-include docs/bbdocs/*
+include docs/bbdocs/*.py
 include docs/developer/*
 include docs/relnotes/*
 

master/buildbot/changes/mail.py

@@ -218,7 +218,6 @@ def parse(self, m, prefix=None):
             raise ValueError('Expected cvsmode 1.11 or 1.12. got: %s' % cvsmode)
 
         log.msg("CVSMaildirSource processing filelist: %s" % fileList)
-        links = []
         while(fileList):
             m = singleFileRE.match(fileList)
             if m:
@@ -240,7 +239,7 @@ def parse(self, m, prefix=None):
                             isdir=isdir, when=when, branch=branch,
                             revision=rev, category=category,
                             repository=cvsroot, project=project,
-                            links=links, properties=self.properties))
+                            properties=self.properties))
 
 # svn "commit-email.pl" handler.  The format is very similar to freshcvs mail;
 # here's a sample:

master/buildbot/status/web/change_hook.py

@@ -63,8 +63,8 @@ def render_POST(self, request):
         except ValueError, err:
             request.setResponseCode(400, err.args[0])
             return err.args[0]
-        except Exception:
-            log.err(None, "Exception processing web hook.")
+        except Exception, e:
+            log.err(e, "processing changes from web hook")
             msg = "Error processing changes."
             request.setResponseCode(500, msg)
             return msg
@@ -78,7 +78,8 @@ def render_POST(self, request):
         def ok(_):
             request.setResponseCode(202)
             request.finish()
-        def err(_):
+        def err(why):
+            log.err(why, "adding changes from web hook")
             request.setResponseCode(500)
             request.finish()
         d.addCallbacks(ok, err)

master/buildbot/status/web/hooks/base.py

@@ -56,6 +56,8 @@ def firstOrNothing( value ):
 
         revision = firstOrNothing(args.get('revision'))
         when     = firstOrNothing(args.get('when'))
+        if when is not None:
+            when = float(when)
         author = firstOrNothing(args.get('author'))
         if not author:
             author = firstOrNothing(args.get('who'))

master/buildbot/test/unit/test_master.py

@@ -223,7 +223,7 @@ def make_master(_):
             self.patch(master.BuildMaster, 'create_child_services',
                     lambda self : None)
 
-            # patch out a few other annoying things the msater likes to do
+            # patch out a few other annoying things the master likes to do
             self.patch(monkeypatches, 'patch_all', lambda : None)
             self.patch(signal, 'signal', lambda sig, hdlr : None)
             self.patch(master, 'Status', lambda master : mock.Mock()) # XXX temporary

master/buildbot/test/unit/test_status_web_change_hook.py

@@ -96,16 +96,16 @@ def testDefaultDialectWithChange(self):
         self.request.args = { "category" : ["mycat"],
                        "files" : [json.dumps(['file1', 'file2'])],
                        "repository" : ["myrepo"],
-                       "when" : [1234],
+                       "when" : ["1234"],
                        "author" : ["Santa Claus"],
-                       "number" : [2],
+                       "number" : ["2"],
                        "comments" : ["a comment"],
                        "project" : ["a project"],
                        "at" : ["sometime"],
                        "branch" : ["a branch"],
                        "revlink" : ["a revlink"],
                        "properties" : [json.dumps( { "prop1" : "val1", "prop2" : "val2" })],
-                       "revision" : [99] }
+                       "revision" : ["99"] }
         d = self.request.test_render(self.changeHook)
         def check_changes(r):
             self.assertEquals(len(self.request.addedChanges), 1)
@@ -115,7 +115,7 @@ def check_changes(r):
             self.assertEquals(change["when"], 1234)
             self.assertEquals(change["author"], "Santa Claus")
             self.assertEquals(change["src"], None)
-            self.assertEquals(change["revision"], 99)
+            self.assertEquals(change["revision"], "99")
             self.assertEquals(change["comments"], "a comment")
             self.assertEquals(change["project"], "a project")
             self.assertEquals(change["branch"], "a branch")

master/docs/developer/cls-buildsteps.rst

@@ -123,7 +123,7 @@ BuildStep
 
         If the step is tracking progress, this is a :class:`~buildbot.status.progress.StepProgress` instance performing that task.
 
-    Exeuction of the step itself is governed by the following methods and attributes.
+    Execution of the step itself is governed by the following methods and attributes.
 
     .. py:method:: startStep(remote)
 
@@ -402,7 +402,7 @@ LoggingBuildStep
         This hook should decide what result the step should have.
         The default implementation invokes ``log_eval_func`` if it exists, and looks at :attr:`~buildbot.process.buildstep.RemoteCommand.rc` to distinguish :data:`~buildbot.status.results.SUCCESS` from :data:`~buildbot.status.results.FAILURE`.
 
-    The remaining methods provide an embarassment of ways to set the summary of the step that appears in the various status interfaces.
+    The remaining methods provide an embarrassment of ways to set the summary of the step that appears in the various status interfaces.
     The easiest way to affect this output is to override :meth:`~BuildStep.describe`.
     If that is not flexible enough, override :meth:`getText` and/or :meth:`getText2`.
 
@@ -413,7 +413,7 @@ LoggingBuildStep
         :returns: a list of short strings
 
         This method is the primary means of describing the step.
-        The default implementation calls :meth:`~BuildStep.describe`, which is usally the easiest method to override, and then appends a string describing the step status if it was not successful.
+        The default implementation calls :meth:`~BuildStep.describe`, which is usually the easiest method to override, and then appends a string describing the step status if it was not successful.
 
     .. py:method:: getText2(command, results)
 

master/docs/developer/cls-irenderable.rst

@@ -11,4 +11,4 @@ IRenderable
 
         :param iprops: the :class:`~buildbot.interfaces.IProperties` provider supplying the properties of the build.
 
-        Reeturns the interpretation of the given properties, optionally in a Deferred.
+        Returns the interpretation of the given properties, optionally in a Deferred.

master/docs/developer/config.rst

@@ -96,7 +96,7 @@ described in :ref:`developer-Reconfiguration`.
 
     .. py:attribute:: codebaseGenerator
     
-        A callable, or None, used to determine the codebase from an incomming 
+        A callable, or None, used to determine the codebase from an incoming 
         :py:class:`~buildbot.changes.changes.Change`,
         from :bb:cfg:`codebaseGenerator`
 
@@ -117,7 +117,7 @@ described in :ref:`developer-Reconfiguration`.
 
     .. py:attribute:: manhole
 
-        The manhole instance to ues, or None; from :bb:cfg:`manhole`.
+        The manhole instance to use, or None; from :bb:cfg:`manhole`.
 
     The remaining attributes contain compound configuration structures, usually
     dictionaries:
@@ -264,9 +264,9 @@ configuration - change sources, slaves, schedulers, build steps, and so on.
     :raises: :py:exc:`ConfigErrors` if called at build-time
 
     This function reports a configuration error. If a config file is being loaded,
-    then the function merely records ther error, and allows he rest of the configuration
+    then the function merely records the error, and allows the rest of the configuration
     to be loaded. At any other time, it raises :py:exc:`ConfigErrors`.  This is done
-    so all config erros can be reported, rather than just the first.
+    so all config errors can be reported, rather than just the first.
 
 .. py:exception:: ConfigErrors([errors])
 
@@ -292,7 +292,7 @@ configuration - change sources, slaves, schedulers, build steps, and so on.
 Reconfiguration
 ===============
 
-When the buildmaster receives a signal to beging a reconfig, it re-reads the
+When the buildmaster receives a signal to begin a reconfig, it re-reads the
 configuration file, generating a new :py:class:`MasterConfig` instance, and
 then notifies all of its child services via the reconfig mechanism described
 below.  The master ensures that at most one reconfiguration is taking place at

master/docs/developer/database.rst

@@ -6,7 +6,7 @@ Database
 As of version 0.8.0, Buildbot has used a database as part of its storage
 backend.  This section describes the database connector classes, which allow
 other parts of Buildbot to access the database.  It also describes how to
-modify the database schema and the connector classes themsleves.
+modify the database schema and the connector classes themselves.
 
 .. note::
 
@@ -162,7 +162,7 @@ buildrequests
         :raises: :py:exc:`AlreadyClaimedError`
 
         Re-claim the given build requests, updating the timestamp, but checking
-        that the requsts are owned by this master.  The resulting deferred will
+        that the requests are owned by this master.  The resulting deferred will
         fire normally on success, or fail with :py:exc:`AlreadyClaimedError` if
         *any* of the build requests are already claimed by another master
         instance, or don't exist.  In this case, none of the reclaims will take
@@ -967,7 +967,7 @@ Database Schema
 .. py:module:: buildbot.db.model
 
 Database connector methods access the database through SQLAlchemy, which
-requires access to Python objects represenging the database tables.  That is
+requires access to Python objects representing the database tables.  That is
 handled through the model.
 
 .. py:class:: Model
@@ -1057,7 +1057,7 @@ Tests
 It goes without saying that any new connector methods must be fully tested!
 
 You will also want to add an in-memory implementation of the methods to the
-fake classes in ``master/budilbot/test/fake/fakedb.py``.  Non-DB Buildbot code
+fake classes in ``master/buildbot/test/fake/fakedb.py``.  Non-DB Buildbot code
 is tested using these fake implementations in order to isolate that code from
 the database code.
 
@@ -1082,7 +1082,7 @@ be complex and require caution so as not to lose information.
 
 Create a new script in :bb:src:`master/buildbot/db/migrate/versions`, following
 the numbering scheme already present.  The script should have an ``update``
-method, which takes an engine as a parameter, and ugprades the database, both
+method, which takes an engine as a parameter, and upgrades the database, both
 changing the schema and performing any required data migrations.  The engine
 passed to this parameter is "enhanced" by SQLAlchemy-Migrate, with methods to
 handle adding, altering, and dropping columns.  See the SQLAlchemy-Migrate
@@ -1172,5 +1172,5 @@ query specifying id's that are IN a subquery will not work.  The workaround is
 to run the subquery directly, and then execute a DELETE query for each returned
 id.
 
-If this weakness has a significant peformance impact, it would be acceptable to
+If this weakness has a significant performance impact, it would be acceptable to
 conditionalize use of the subquery on the database dialect.

master/docs/developer/master-overview.rst

@@ -23,7 +23,7 @@ The master has several child services:
     A :py:class:`buildbot.process.metrics.MetricLogObserver` instance that
     handles tracking and reporting on master metrics.
 
-``msater.caches``
+``master.caches``
     A :py:class:`buildbot.process.caches.CacheManager` instance that provides
     access to object caches.
 

master/docs/developer/master-slave.rst

@@ -379,7 +379,7 @@ following arguments:
 
 ``mode``
 
-    Acess mode for the new file.
+    Access mode for the new file.
 
 The reader object's ``read(maxsize)`` method will be called with a maximum
 size, which will return no more than that number of bytes as a bytestring.  At
@@ -393,7 +393,7 @@ mkdir
 .....
 
 This command will create a directory on the slave.  It will also create any
-intervening directories required.  It takes the following arugment:
+intervening directories required.  It takes the following argument:
 
 ``dir``
 

master/docs/developer/metrics.rst

@@ -57,7 +57,7 @@ monitor. There are three sub-classes implemented:
 Metric Handlers
 ---------------
 
-:class:`MetricsHandler` objects are responsble for collecting
+:class:`MetricsHandler` objects are responsible for collecting
 :class:`MetricEvent`\s of a specific type and keeping track of their
 values for future reporting. There are :class:`MetricsHandler` classes
 corresponding to each of the :class:`MetricEvent` types. 

master/docs/developer/tests.rst

@@ -201,7 +201,7 @@ For testing things that themselves depend on time, consider using
 :class:`twisted.internet.tasks.Clock`.  This may mean passing a clock instance to
 the code under test, and propagating that instance as necessary to ensure that
 all of the code using :meth:`callLater` uses it.  Refactoring code for
-testability is difficult, but wortwhile.
+testability is difficult, but worthwhile.
 
 For testing things that do not depend on time, but for which you cannot detect
 the "end" of an operation: add a way to detect the end of the operation!

master/docs/developer/utils.rst

@@ -467,7 +467,7 @@ apply that to a non-network situation.
         :param data: a portion of netstring-formatted data
         :raises: :py:exc:`twisted.protocols.basic.NetstringParseError`
 
-        Add arbitrariliy-sized ``data`` to the incoming-data buffer.  Any
+        Add arbitrarily-sized ``data`` to the incoming-data buffer.  Any
         complete netstrings will trigger a call to the
         :py:meth:`stringReceived` method.
 
@@ -523,7 +523,7 @@ buildbot.util.croniter
 ~~~~~~~~~~~~~~~~~~~~~~
 
 This module is a copy of https://github.com/taichino/croniter, and provides
-suport for converting cron-like time specifications into actual times.
+support for converting cron-like time specifications into actual times.
 
 buildbot.util.state
 ~~~~~~~~~~~~~~~~~~~
@@ -537,7 +537,7 @@ The classes in the :py:mod:`buildbot.util.subscription` module are used for deal
 
     .. py:attribute:: name
 
-         This must be set to the name to be used to identifiy this object in the database.
+         This must be set to the name to be used to identify this object in the database.
 
     .. py:attribute:: master
 

master/docs/manual/cfg-builders.rst

@@ -29,7 +29,7 @@ configuration file, its use looks like::
 ``slavenames``
     These arguments specify the buildslave or buildslaves that will be used by
     this Builder.  All slaves names must appear in the :bb:cfg:`slaves`
-    configuration parameter. Each buildslave can accomodate multiple
+    configuration parameter. Each buildslave can accommodate multiple
     builders.  The ``slavenames`` parameter can be a list of names,
     while ``slavename`` can specify only one slave.
 

master/docs/manual/cfg-buildslaves.rst

@@ -177,7 +177,7 @@ Amazon Web Services Elastic Compute Cloud ("AWS EC2")
 
 `EC2 <http://aws.amazon.com/ec2/>`_ is a web service that allows you to
 start virtual machines in an Amazon data center. Please see their website for
-details, incuding costs. Using the AWS EC2 latent buildslaves involves getting
+details, including costs. Using the AWS EC2 latent buildslaves involves getting
 an EC2 account with AWS and setting up payment; customizing one or more EC2
 machine images ("AMIs") on your desired operating system(s) and publishing
 them (privately if needed); and configuring the buildbot master to know how to