It seems like issue is getting in spot instances. Doesn't seem like anything specific to patch or test framework. I dont think we have much choice there rather than let tests to take whatever time they take. So, killing a test run won't help much, I guess.
Thanks, Ashutosh On Wed, Mar 19, 2014 at 2:56 PM, Xuefu Zhang <[EMAIL PROTECTED]> wrote:
Thanks for keeping an eye. There's another point worth mentioning, that a confusing, others had also reported about the same situation. The pre-commit test run can seem to take long because its waiting for the the PTest server to finish the other hive builds (trunk/0.13), which I believed happened here too. See: http://bigtop01.cloudera.org:8080/view/Hive/builds
Pre-commit, Trunk, and 0.13 builds run sequentially on the same infrastructure, and throttle is at the server, thus Jenkins reports more time than the actual runtime.
After 0.13 is released, that branch build can be disabled, and it will be back up to better capacity with just pre-commit and trunk builds.
On Wed, Mar 19, 2014 at 3:43 PM, Xuefu Zhang <[EMAIL PROTECTED]> wrote:
I wonder shall we disable all Hive builds except for trunk on hadoop-1 to expedite the queue. Since, thats the primary combination we are using to inform committing patches, that will help to move queue faster. Without patches getting committed (since queue is not moving fast enough) other builds are not of much use. Once, incoming patch stream slows down a bit, we can reeneable more builds. What do other people think?
Thanks, Ashutosh On Wed, Mar 19, 2014 at 4:57 PM, Szehon Ho <[EMAIL PROTECTED]> wrote: