HADOOP-11933: Jenkins pre-commit in a docker container

[Allen Wittenauer <aw...@altiscale.com>]

	
Hi.

	A few times now, we’ve run into issues where we weren’t sure what sort of state the surrounding environment was present when a pre commit patch test was done.  Additionally, there are times when installing or even updating a component was a challenge.   There are some bits that we do not compile or even test as part of the Jenkins run as a result.

	After a bit less than a week of work, I’ve managed to get test-patch.sh smart enough to launch and re-exec itself inside a docker container.  The container definition is part of the source tree.  This effectively means that, after HADOOP-11933 is committed, we’ll be able to have a much greater sense of control over the exact environment that is running during patch test time.  We’ll be able to easily add/remove components as necessary.

	Currently, HADOOP-11933 is awaiting review.  But I thought I’d pop this message out here so that more people are aware of the patch as well as if there are any thoughts/concerns/feature requests/etc prior to any potential commit. It should be noted that Jenkins’ precommit has the flags configured such that when test-patch.sh re-exec’s itself to test the patch, it does so in a docker container. In other words, the docker container patch is testing itself in a docker container. :)  (Other patches ignore those flags since this patch isn’t live yet.)

Thanks.