| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Framework for writing test cases to be submitted with patches.
This framework and the test cases get exercised by Jenkins in
the pre-commit regression test. Jenkins is configured to give
a +1 verified vote only if the regression test passes without
failures (which includes test cases added/changed by the patch
being tested)
Every patch should include a test case (either extensions/changes
to existing test cases or add new ones, as appropriate). The test
case should be part of the same commit so that both code and
test case get reviewed together.
Test cases added are cumulative. Every new patch gets
tested against its own test case and every test case previously
added.
A lot of new commits in the near future will be pure test cases
(with no code change) which will get added in "catch up" mode.
The tool used for implementing test cases is 'prove', and the
framework itself is modeled similar to the POSIX compliance
filesystem test suite.
Under the top level directory, a new directory named 'tests/'
is added. This contains top level classifier directories and
framework files/scripts.
Functionality tests should be created under a classifier directory
below 'tests/'. For e.g:
tests/basic/mount.t
tests/performance/write-behind.t
Bugs which get fixed should include a test case script named
by the bug id, so that we are guaranteed any new change will
not bring the issue back. For e.g:
tests/bugs/bug-123456.t
Triggering of regression tests in Jenkins is manual at this point
as we do not want the entire test suite to run against every
revision of a patch while it is still in the review/resubmit cycle.
Signed-off-by: Anand Avati <avati@redhat.com>
Change-Id: I8078244619135ccaba38e068925f8ca85141055a
BUG: 764966
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.org/4101
Tested-by: Gluster Build System <jenkins@build.gluster.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
as it is changed in RPM based install (using spec file), makes sense to do
it everywhere, even in source install
Change-Id: Ibe5ebd860b1529aca295b79d683a3b2e6797506c
Signed-off-by: Amar Tumballi <amar@gluster.com>
BUG: 824231
Reviewed-on: http://review.gluster.com/3338
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
| |
|
|
|
|
|
|
| |
Change-Id: I6d58e387e2bf9d5616ec3950abdb0680801523db
BUG: 3234
Reviewed-on: http://review.gluster.com/564
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra Bhat <raghavendrabhat@gluster.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
gluster cli now checks the brick order when creating
a replicate or distributed-replicate volume.
If a non-optimal order is found the user is given a
warning and asked if the volume creation can proceed.
Change-Id: I38c4cb65bffb40ccf95319cf3f4f3423a4cdebe9
BUG: 2407
Reviewed-on: http://review.gluster.com/151
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
|
|
|
Change-Id: Idc3be3e22cca5fc623b27c2f500f59785cbd332b
BUG: 3234
Reviewed-on: http://review.gluster.com/262
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
