[Gluster-devel] Reducing regression runs (hopefully)
Jeff Darcy
jdarcy at redhat.com
Mon Jul 25 13:47:20 UTC 2016
> My vision in this regard is something like this:
> * A patchset gets Verified +1.
> * A meta job is kicked off which determines regression jobs to run.
> If the patch only touches GFAPI, we kick off the GFAPI regression tests. If
> it touches multiple modules, we kick off the tests for these specific
> modules.
I think we do need to be a bit careful here. Tests for one component often
do affect other components. For example, a change to xlators/protocol/server
will potentially affect every test, so we can't just run tests for that one
component. What I was getting at was the extreme case where we can be
absolutely certain that component X is not even loaded for test Y.
One could argue that we should let burn-in catch interactions between
components that are "distant" from one another, and not test one for every
single change to the other. I'm not against that idea, but it's not quite
the same as the case where X and Y could not *possibly* interact.
> * The results for each platform are aggregated under our current labels
> similar
> to how we aggregate results of multiple tests into one label for smoke.
>
> Am I being too ambitious here? Is there something I'm missing?
It's pretty ambitious, but only you can say whether it's too much so. If
you feel comfortable with that level of Gerrit/Jenkins voodoo, go for it!
More information about the Gluster-devel
mailing list