mariadb/mysql-test/collections
2009-02-25 15:00:17 +01:00
..
default.daily Bug#42888 for MySQL 5.1. Add collections of test runs to make it both configurable and transparent what kinds of tests we run during integration testing. Implement filter list in mysql-test-run.pl to filter out failures of experimental test cases, using a new status code "exp-fail", so we can tell regressions ("fail") from failures of test cases that are still in development ("exp-fail"). 2009-02-24 12:53:34 +01:00
default.experimental Bug#42888 for MySQL 5.1. Add collections of test runs to make it both configurable and transparent what kinds of tests we run during integration testing. Implement filter list in mysql-test-run.pl to filter out failures of experimental test cases, using a new status code "exp-fail", so we can tell regressions ("fail") from failures of test cases that are still in development ("exp-fail"). 2009-02-24 12:53:34 +01:00
default.push Bug#42888 for MySQL 5.1. Add collections of test runs to make it both configurable and transparent what kinds of tests we run during integration testing. Implement filter list in mysql-test-run.pl to filter out failures of experimental test cases, using a new status code "exp-fail", so we can tell regressions ("fail") from failures of test cases that are still in development ("exp-fail"). 2009-02-24 12:53:34 +01:00
default.weekly bug#42888: Add collections of test runs to make it both configurable and 2009-02-24 11:42:11 +01:00
README bug#42888: Add collections of test runs to make it both configurable and 2009-02-24 11:42:11 +01:00
README.experimental address review comments 2009-02-25 15:00:17 +01:00

This directory contains collections of test runs that we run during our
integration and release testing. Each file contains zero or more lines,
with one invocation of mysql-test-run.pl on each. These invocations are
written so that, with the assumption that perl is in your search path,
any collection can run as a shell script or a batch file, with the parent
mysql-test directory being the current working directory.

During integration testing, we choose the collection to run by following
these steps:

1) We choose the extension to look for, based on these rules:
   - If we're running a per-push test, we choose ".push" as the extension.
   - If we're running a daily test, we choose ".daily" as the extension.
   - If we're running a weekly test, we choose ".weekly" as the extension.

2) If there is a collection that has the same name as the branch we're
   testing plus the extension as determined in step 1, we choose that
   collection.

3) If the branch is unknown or we have removed all characters from it
   and still not found a matching collection, we choose the name "default"
   plus the extension determined in step 1. If there is no such file,
   we give up and don't test anything at all.

4) If we haven't found a collection yet, we remove the last character from 
   the branch name and go back to step 2.

5) The commands from the collection are run line by line via execv() or
   similar system calls. They are not run as a shell script. Shell 
   expansions are not guaranteed to work and most likely won't.