Re: reverting test-breaking changes

TestNegativeCliDriver failures are concerning. We are practically having no negative test coverage since a last couple of weeks. I think we should treat it as a blocker for Hive 3.0.0 release. Thoughts? On Thu, Apr 5, 2018 at 9:50 PM, Prasanth Jayachandran < pjayachand...@hortonworks.com> wrote:

Re: reverting test-breaking changes

It may be because of legitimate memory issue/leak. Alternative is to decrease the batch size of negative cli driver on ptest cluster but again we wouldn't know if there is any actual memory issue. Thanks Prasanth On Thu, Apr 5, 2018 at 1:36 PM -0700, "Vineet Garg" mailto:vg...@hortonworks.co

Re: reverting test-breaking changes

TestNegativeCli driver tests are still failing with java.lang.OutOfMemoryError: GC overhead limit exceeded error. Can we increase the amount of memory for tests? Vineet On Mar 5, 2018, at 11:35 AM, Sergey Shelukhin mailto:ser...@hortonworks.com>> wrote: On a semi-related note, I noticed recent

Re: reverting test-breaking changes

On a semi-related note, I noticed recently that negative tests seem to OOM in setup from time to time. Can we increase the amount of memory for the tests a little bit, and/or maybe add the dump on OOM to them, saved to test logs directory, so we could investigate? On 18/3/5, 11:07, "Vineet Garg"

Re: reverting test-breaking changes

+1 for nightly build. We could generate reports to identify both frequent and sporadic test failures plus other interesting bits like average build time, yetus failures etc. It’ll also help narrow down the culprit commit(s) range to one day. If you guys decide to go ahead with this I would like

Re: reverting test-breaking changes

Wow that HBase UI looks super useful. +1 to having something like that. If not, +1 to having a proper nightly build, it would help devs identify which commits break which tests. I find using git-bisect can take a long time to run, and can be difficult to use (e.g. finding a known good commit isn't

Re: reverting test-breaking changes

Without a nightly build and with this many flaky tests it is very hard to identify the braking commits. We can use something like bisect and multiple test runs. There is a more elegant way to do this with nightly test runs: https://issues.apache.org/jira/browse/HBASE-15917

Re: reverting test-breaking changes

+1 Does anyone have suggestions about how to efficiently identify which commit is breaking a test? Is it just git-bisect or is there an easier way? Hive QA isn't always that helpful, it will say a test is failing for the past "x" builds, but that doesn't help much since Hive QA isn't a nightly bui

Re: reverting test-breaking changes

+1 Commenting on JIRA and giving a 24hr heads-up (excluding weekends) would be good. On Thu, Feb 22, 2018 at 10:19 AM, Alan Gates wrote: > +1. > > Alan. > > On Thu, Feb 22, 2018 at 8:25 AM, Thejas Nair > wrote: > > > +1 > > I agree, this makes sense. The number of failures keeps increasing. > >

Re: reverting test-breaking changes

+1. Alan. On Thu, Feb 22, 2018 at 8:25 AM, Thejas Nair wrote: > +1 > I agree, this makes sense. The number of failures keeps increasing. > A 24 hour heads up in either case before revert would be good. > > > On Thu, Feb 22, 2018 at 2:45 AM, Peter Vary wrote: > > > I agree with Zoltan. The cont

Re: reverting test-breaking changes

+1 I agree, this makes sense. The number of failures keeps increasing. A 24 hour heads up in either case before revert would be good. On Thu, Feb 22, 2018 at 2:45 AM, Peter Vary wrote: > I agree with Zoltan. The continuously braking tests make it very hard to > spot real issues. > Any thoughts

Re: reverting test-breaking changes

I agree with Zoltan. The continuously braking tests make it very hard to spot real issues. Any thoughts on doing it automatically? > On Feb 22, 2018, at 10:47 AM, Zoltan Haindrich wrote: > > * > > Hello, > > * > * > > ** > > In the last couple weeks the number of broken tests have started t

reverting test-breaking changes

* Hello, * * ** In the last couple weeks the number of broken tests have started to go up...and even tho I run bisect/etc from time to time ; sometimes people don’t react to my comments/tickets/etc. Because keeping this many failing tests makes it easier for a new one to slip in...I think