hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)
Date Tue, 16 Jun 2015 16:59:34 GMT

Since a couple of people have brought it up:

	I think the release question is probably one of the big question marks.  Other than tar balls,
how does something like this actually get used downstream?

	For test-patch, in particular, I have a few thoughts on this:

Short term:

	* Projects that want to move RIGHT NOW would modify their Jenkins jobs to checkout from the
Yetus repo (preferably at a well known tag or branch) in one directory and their project repo
in another directory.  Then it’s just a matter of passing the correct flags to test-patch.
 This is pretty much how I’ve been personally running test-patch for about 6 months now.
Under Jenkins, we’ve seen this work with NiFi (incubating) already.

	* Create a stub version of test-patch that projects could check into their repo, replacing
the existing test-patch.  This stub version would git clone from either ASF or github and
then execute test-patch accordingly on demand.  With the correct smarts, it could make sure
it has a cached version to prevent continual clones.

Longer term:

	* I’ve been toying with the idea of (ab)using Java repos and packaging as a transportation
layer, either in addition or in combination with something like a maven plugin.  Something
like this would clearly be better for offline usage and/or to lower the network traffic.

	It’s probably worth pointing out that plugins can get sucked in from outside the Yetus
dir structure, so project specific bits can remain in those projects.  This would mean that,
e.g., if ambari decides they want to change the dependency ordering such that ambari-metrics
always gets built first, that’s completely doable without the Yetus project getting involved.
 This is particularly relevant for things like the Dockerfile where projects would almost
certainly want to dictate their build and test time dependencies.  
View raw message