On Mon, Jul 25, 2016 at 6:08 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
> I have a few proposals to reduce this turn around time:
>
> 1. We do not clear the Verified tag. This means if you want to re-run
> regressions you have to manually trigger it. If your patch is rebased on
> top
> of another patch, you may have to retrigger failing regressions manually.
> 2. We do give automatic +1 for regressions if the change is *only* in
> `extras/`, to MAINTAINERS file and other no-op changes. Please correct me
> here. I think the changes here do not affect regressions. If I'm wrong and
> they do, I'd love to know which files do affect regressions. I've taken
> the
> MAINTAINERS file as an example, I'm also curious to know what other no-op
> changes can be made.
I think you're on the right track here, Nigel. :) I'd also add that changes
to one .t file shouldn't require that any others be run (the same is not true
of .rc files though).
+1
On the more ambitious side, I think we could also optimize around the idea
that some parts of the system aren't even present for some tests. For
example, most of our tests don't even use GFAPI and won't be affected by a
GFAPI-only change. Conversely, GFAPI tests won't be affected by a FUSE-only
change. AFR, EC, and JBR code and tests are mutually exclusive in much the
same way. We have the burn-in test to catch "stragglers" and git to revert
any patch with surprising effects, so IMO (at least on master) we should be
pretty aggressive about pruning out tests that provide little value.
Yes. We introduced #G_TESTDEF_* keys in our .t files with the same idea. Currently, we have two keys
a. G_TESTDEF_TEST_STATUS_CENTOS6
b. G_TESTDEF_TEST_STATUS_NETBSD7
Value for these keys is used by our framework to determine[1] whether to run the test or not. It is fairly easy to add more keys. To take the same example of a GFAPI change,
G_TESTDEF_TESTS_COMPONENTS="gfapi,dht,afr,"
G_TESTDEF_NO_IMPACT_COMPONENTS="fuse"
Combination of values from these two keys would decide whether to trigger the test for a change in a component or not.
If you wish to provide such feature and implement in any different way, ensure that such feature should be usable by the developer on his/her laptop. Hence, it is better if it is developed in the framework than in jenkins/gerrit configuration.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
