-
Notifications
You must be signed in to change notification settings - Fork 0
Buildbot Options
There are a number of ways to control the ZFS Buildbot at a commit level. This page provides a summary of various options that the ZFS Buildbot supports and how it impacts testing. More detailed information regarding its implementation can be found at the ZFS Buildbot Github page.
By default, all commits in your ZFS pull request are compiled by the BUILD
builders. Additionally, the top commit of your ZFS pull request is tested by
TEST builders. However, there is the option to override which types of builder
should be used on a per commit basis. In this case, you can add
Requires-builders: <none|all|style|build|arch|distro|test|perf|coverage|unstable>
to your
commit message. A comma separated list of options can be
provided. Supported options are:
-
all
: This commit should be built by all available builders -
none
: This commit should not be built by any builders -
style
: This commit should be built by STYLE builders -
build
: This commit should be built by all BUILD builders -
arch
: This commit should be built by BUILD builders tagged as 'Architectures' -
distro
: This commit should be built by BUILD builders tagged as 'Distributions' -
test
: This commit should be built and tested by the TEST builders (excluding the Coverage TEST builders) -
perf
: This commit should be built and tested by the PERF builders -
coverage
: This commit should be built and tested by the Coverage TEST builders -
unstable
: This commit should be built and tested by the Unstable TEST builders (currently only the Fedora Rawhide TEST builder)
A couple of examples on how to use Requires-builders:
in commit messages can be found below.
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Requires-builders: none
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Requires-builders: style test
Currently, the ZFS Buildbot attempts to choose the correct SPL branch to build
based on a pull request's base branch. In the cases where a specific SPL version
needs to be built, the ZFS buildbot supports specifying an SPL version for pull
request testing. By opening a pull request against ZFS and adding Requires-spl:
in a commit message, you can instruct the buildbot to use a specific SPL version.
Below are examples of a commit messages that specify the SPL version.
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Requires-spl: refs/pull/123/head
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Requires-spl: spl-branch-name
Currently, Kernel.org builders will clone and build the master branch of Linux.
In cases where a specific version of the Linux kernel needs to be built, the ZFS
buildbot supports specifying the Linux kernel to be built via commit message.
By opening a pull request against ZFS and adding Requires-kernel:
in a commit
message, you can instruct the buildbot to use a specific Linux kernel.
Below is an example commit message that specifies a specific Linux kernel tag.
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Requires-kernel: v4.14
Each builder will execute or skip build steps based on its default preferences. In some scenarios, it might be possible to skip various build steps. The ZFS buildbot supports overriding the defaults of all builders in a commit message. The list of available overrides are:
-
Build-linux: <Yes|No>
: All builders should build Linux for this commit -
Build-lustre: <Yes|No>
: All builders should build Lustre for this commit -
Build-spl: <Yes|No>
: All builders should build the SPL for this commit -
Build-zfs: <Yes|No>
: All builders should build ZFS for this commit -
Built-in: <Yes|No>
: All Linux builds should build in SPL and ZFS -
Check-lint: <Yes|No>
: All builders should perform lint checks for this commit -
Configure-lustre: <options>
: Provide<options>
as configure flags when building Lustre -
Configure-spl: <options>
: Provide<options>
as configure flags when building the SPL -
Configure-zfs: <options>
: Provide<options>
as configure flags when building ZFS
A couple of examples on how to use overrides in commit messages can be found below.
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Build-lustre: Yes
Configure-lustre: --disable-ldiskfs
Build-spl: No
This is a commit message
This text is part of the commit message body.
Signed-off-by: Contributor <[email protected]>
Build-lustre: No
Build-spl: No
At the top level of the ZFS source tree, there is the TEST
file which contains variables
that control if and how a specific test should run. Below is a list of each variable
and a brief description of what each variable controls.
-
TEST_PREPARE_WATCHDOG
- Enables the Linux kernel watchdog -
TEST_PREPARE_SHARES
- Start NFS and Samba servers -
TEST_SPLAT_SKIP
- Determines ifsplat
testing is skipped -
TEST_SPLAT_OPTIONS
- Command line options to provide tosplat
-
TEST_ZTEST_SKIP
- Determines ifztest
testing is skipped -
TEST_ZTEST_TIMEOUT
- The length of timeztest
should run -
TEST_ZTEST_DIR
- Directory whereztest
will create vdevs -
TEST_ZTEST_OPTIONS
- Options to pass toztest
-
TEST_ZTEST_CORE_DIR
- Directory forztest
to store core dumps -
TEST_ZIMPORT_SKIP
- Determines ifzimport
testing is skipped -
TEST_ZIMPORT_DIR
- Directory used duringzimport
-
TEST_ZIMPORT_VERSIONS
- Source versions to test -
TEST_ZIMPORT_POOLS
- Names of the pools forzimport
to use for testing -
TEST_ZIMPORT_OPTIONS
- Command line options to provide tozimport
-
TEST_XFSTESTS_SKIP
- Determines ifxfstest
testing is skipped -
TEST_XFSTESTS_URL
- URL to downloadxfstest
from -
TEST_XFSTESTS_VER
- Name of the tarball to download fromTEST_XFSTESTS_URL
-
TEST_XFSTESTS_POOL
- Name of pool to create and used byxfstest
-
TEST_XFSTESTS_FS
- Name of dataset for use byxfstest
-
TEST_XFSTESTS_VDEV
- Name of the vdev used byxfstest
-
TEST_XFSTESTS_OPTIONS
- Command line options to provide toxfstest
-
TEST_ZFSTESTS_SKIP
- Determines ifzfs-tests
testing is skipped -
TEST_ZFSTESTS_DIR
- Directory to store files and loopback devices -
TEST_ZFSTESTS_DISKS
- Space delimited list of disks thatzfs-tests
is allowed to use -
TEST_ZFSTESTS_DISKSIZE
- File size of file based vdevs used byzfs-tests
-
TEST_ZFSTESTS_ITERS
- Number of timestest-runner
should execute its set of tests -
TEST_ZFSTESTS_OPTIONS
- Options to providezfs-tests
-
TEST_ZFSTESTS_RUNFILE
- The runfile to use when runningzfs-tests
-
TEST_ZFSTESTS_TAGS
- List of tags to provide totest-runner
-
TEST_ZFSSTRESS_SKIP
- Determines ifzfsstress
testing is skipped -
TEST_ZFSSTRESS_URL
- URL to downloadzfsstress
from -
TEST_ZFSSTRESS_VER
- Name of the tarball to download fromTEST_ZFSSTRESS_URL
-
TEST_ZFSSTRESS_RUNTIME
- Duration to runrunstress.sh
-
TEST_ZFSSTRESS_POOL
- Name of pool to create and use forzfsstress
testing -
TEST_ZFSSTRESS_FS
- Name of dataset for use duringzfsstress
tests -
TEST_ZFSSTRESS_FSOPT
- File system options to provide tozfsstress
-
TEST_ZFSSTRESS_VDEV
- Directory to store vdevs for use duringzfsstress
tests -
TEST_ZFSSTRESS_OPTIONS
- Command line options to provide torunstress.sh
- Home
- Getting Started
- Project and Community
- Developer Resources
- Performance and Tuning