There may be times that you wish to influence the building and testing carried out on your change. You might for example be fixing an issue that affects a particular distribution or combination of distributions, for this reason you can change the tests carried out by indicating in the commit message the changes you require.
To do this place the following comments with space-separated name value pairs in your commit message:
Test-Parameters: n=v x=y
To cater for multiple requirements we allow for lists of requirements, with each entry being a separate test:
Test-Parameters: x=y c=e Test-Parameters: e=z r=e
Long lists can be catered for by escaping the carriage return:
Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 envdefinitions=SLOW=yes \ testlist=sanity,liblustre
Multiple tests are separated by a comma, and can be specified multiple times:
Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 envdefinitions=SLOW=yes \ testlist=replay-dual,replay-single,replay-dual,replay-single,replay-single,replay-dual
fortestonly
Test-Parameters supplied with a normal commit are in addition to the normal tests that would be run against a patch. This allows a patch with specific or unusual testing requirements to ensure that sufficient additional testing is run to gain confidence in the change being made. For patches that are of an experimental nature (i.e. developer is not sure of functionality, or only wants a limited set of tests to be run), it is also possible to submit a patch with the fortestonly parameter.
The fortestonly parameter marks that the patch is not intended for landing. Supplied Test-Parameters override the default tests that will be run, so it is possible to run only a subset of tests, possibly multiple times each.
Permissible Test-Parameters:
Name | Description | Valid Values |
|---|---|---|
fortestonly | Commit is not indended for landing |
|
ostcount | Number of OSTs per OSS to test against | 1.. |
mdscount | Number of MDSs to test against | 1 |
mdtcount | Number of MDTs to test against | 1.. |
osscount | Number of OSTs to test against | 1.. |
clientprofile | Cobbler profile to use for clients | test |
serverprofile | Cobbler profile to use for servers | test |
clientdistro | Distribution to use for clients | el5, el6, sles11, sles11sp2 |
serverdistro (A bug exists today which means you need to specify mdsdistro & ossdistro not serverdistro) | Distribution to use for servers | el5, el6, sles11, sles11sp2 |
clientarch | Architecture to use for clients | i686, x86_64 |
serverarch serverdistro (A bug exists today which means you need to specify mdsarch & ossarch not serverarch) | Architecture to use for servers | i686, x86_64 |
clientjob | Jenkins 'job' to fetch from for the clients under test | Any valid jenkins job |
clientbuildno | Jenkins buildno to fetch for the clients under test | Any valid build no for clientjob |
serverjob serverdistro (A bug exists today which means you need to specify mdsjob & ossjob not serverjob) | Jenkins 'job' to fetch from for the servers under test | Any valid jenkins job |
serverbuildno | Jenkins buildno to fetch for the servers under test | Any valid build for serverjob |
nettypes | Network types to use as a comma separated array | tcp, o2ib |
clientcount | Number of clients to use | 2-4 |
ostsizegb | Size of OSTs in gb. Note this is a max size and will be limited by the disk available | >0 |
mdssizegb | Size of MDS in gb. Note this is a max size and will be limited by the disk available | >0 |
mdsfilesystemtype | File system to use for MDSs | zfs, ldiskfs |
mdtfilesystemtype | File system to use for MDTs | zfs, ldiskfs |
ostfilesystemtype | File system to use for OSTs | zfs, ldiskfs |
clientibstack | IB stack to use on the client. | inkernel, ofa |
serveribstack | IB stack to use on the server. | inkernel, ofa |
envdefinitions | Comma separated environment definitions passed to the environment. Be very careful setting environment variables directly (for example OSTFSTYPE=zfs) | AA=BB,CC=DD etc. |
testgroup | Test group to test with | review, regression, full |
testlist | Comma separated list of test names to run in place of a standard test group | sanity,conf_sanity,mmp etc |
You do not need to specify all the values only those values important for your requirements, the test system will use your request to alter a regular test. Also to ensure that you all reviews are fully tested to a known standard. The test system will run a regular, unmodified test set as well as the special request.
Here is an example:
LU-1234 recovery: handle swabbing during recover
Handle byte swabbing of requests properly during recovery. There were
problems with the handling of replayed creates that sent the requests
with client-endian order but a little-endian LOV EA.
Test-Parameters: clientdistro=el5 clientarch=ppc serverarch=x86_64 \
ostcount=10 nettype=tcp testlist=conf-sanity,replay-single
Test-Parameters: clientdistro=sl11 serverdistro=rh6 clientarch=ppc \
nettype=o2ib testlist=conf-sanity,replay-single
Signed-off-by: Random J Developer <random@developer.example.org>
Change-Id: Ica9ed1612eab0c4673dee088f8b441d806c64932
Complex Examples
Test a review for failover
Test-Requirements: fortestonly envdefinitions="SLOW=yes" clientcount=4 osscount=2 mdscount=2 austeroptions=-R failover=true useiscsi=true testgroup=failover
Overview
Content Tools