On Tue, Apr 25, 2017 at 12:50:45PM -0400, Jeff Darcy wrote: > > > > On Mon, Apr 24, 2017, at 11:52 AM, Jeff Darcy wrote: > > On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote: > >> As we don't run our .t files with brick mux being enabled for every > >> patches can we ensure that there is a nightly regression trigger with > >> brick multiplexing feature being enabled. The reason for this ask is > >> very simple, we have no control on the regression for this feature. > >> I've already seen a very basic test (volume status not reflecting > >> bricks online after glusterd restart) breaking recently which used to > >> work earlier.> > > +100 > > FWIW, the way I ran these tests during development was to have a patch > that makes multiplexing the default. I'd periodically rebase that on > top of whatever else was current, then run regressions on that. To do > that as part of a periodic test, we'd need the regression scripts to > look for that same patch in some "well known place" and apply it before > building. Is that something that somebody else would feel comfortable > implementing, or should I look into it?
This "well known place" could be a branch in the git repository, maybe with an obvious name like "for-testing/brick-multiplex". In case the patch needs changing, everyone could then just update it and send a review. Maybe it is even possible to automatically rebase the "for-testing" branch every now and then. A Jenkins job can then checkout the master branch, and merge the "for-testing" branch before running the tests. Or, we have a change on review.gluster.org that never gets merged, and gets cherry-picked before running the regression tests (probably easier). Niels
signature.asc
Description: PGP signature
_______________________________________________ Gluster-infra mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-infra
