| Trees | Indices | Help | 
        
  | 
  
|---|
| 
       | 
  
                    object --+                    
                             |                    
properties.PropertiesMixin --+                    
                             |                    
           buildstep.BuildStep --+                
                                 |                
        buildstep.LoggingBuildStep --+            
                                     |            
              steps.shell.ShellCommand --+        
                                         |        
   steps.shell.WarningCountingShellCommand --+    
                                             |    
                              steps.shell.Test --+
                                                 |
                                                MTR
Build step that runs mysql-test-run.pl, as used in MySQL, Drizzle,
MariaDB, etc.
It uses class MtrLogObserver to parse test results out from the
output of mysql-test-run.pl, providing better completion time
estimates and summarising test failures on the waterfall page.
It also provides access to mysqld server error logs from the test
run to help debugging any problems.
Optionally, it can insert into a database data about the test run,
including details of any test failures.
Parameters:
textLimit
    Maximum number of test failures to show on the waterfall page
    (to not flood the page in case of a large number of test
    failures. Defaults to 5.
testNameLimit
    Maximum length of test names to show unabbreviated in the
    waterfall page, to avoid excessive column width. Defaults to 16.
parallel
    Value of --parallel option used for mysql-test-run.pl (number
    of processes used to run the test suite in parallel). Defaults
    to 4. This is used to determine the number of server error log
    files to download from the slave. Specifying a too high value
    does not hurt (as nonexisting error logs will be ignored),
    however if using --parallel value greater than the default it
    needs to be specified, or some server error logs will be
    missing.
dbpool
    An instance of twisted.enterprise.adbapi.ConnectionPool, or None.
    Defaults to None. If specified, results are inserted into the database
    using the ConnectionPool.
    The class process.mtrlogobserver.EqConnectionPool subclass of
    ConnectionPool can be useful to pass as value for dbpool, to
    avoid having config reloads think the Buildstep is changed
    just because it gets a new ConnectionPool instance (even
    though connection parameters are unchanged).
autoCreateTables
    Boolean, defaults to False. If True (and dbpool is specified), the
    necessary database tables will be created automatically if they do
    not exist already. Alternatively, the tables can be created manually
    from the SQL statements found in the mtrlogobserver.py source file.
test_type
test_info
    Two descriptive strings that will be inserted in the database tables if
    dbpool is specified. The test_type string, if specified, will also
    appear on the waterfall page.
| Nested Classes | |
| MyMtrLogObserver | |
| Instance Methods | |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
      
  | 
  |||
| 
     Inherited from  Inherited from  Inherited from  Inherited from  Inherited from  Inherited from  Inherited from   | 
  |||
| Static Methods | |
| 
     Inherited from   | 
  
| Class Variables | |
        renderables = 
     | 
  |
| 
     Inherited from  Inherited from  Inherited from  Inherited from  Inherited from   | 
  |
| Instance Variables | |
| 
     Inherited from   | 
  
| Properties | |
| 
     Inherited from   | 
  
| Method Details | 
  
 x.__init__(...) initializes x; see help(type(x)) for signature 
  | 
  
 
  | 
  
 
  | 
  
 Run a database transaction with dbpool.runInteraction, but retry the transaction in case of a temporary error (like connection lost). This is needed to be robust against things like database connection idle timeouts. The passed callable that implements the transaction must be retryable, ie. it must not have any destructive side effects in the case where an exception is thrown and/or rollback occurs that would prevent it from functioning correctly when called again.  | 
  
 Run a database query, like with dbpool.runQuery, but retry the query in case of a temporary error (like connection lost). This is needed to be robust against things like database connection idle timeouts.  | 
| Trees | Indices | Help | 
        
  | 
  
|---|
| Generated by Epydoc 3.0.1 on Wed Nov 21 16:22:44 2012 | http://epydoc.sourceforge.net |