I just made TRUNK and branch-1 builds use same jvm as patch-build (hadoopqa) -- i.e. jdku51 -- and I set the MAVEN_OPTS to be the same as those of trunk build too, setting MAVEN_OPTS="-Xmx6100m"... it had been 3000.
Yours, St.Ack On Wed, Dec 31, 2014 at 4:22 PM, Stack <[email protected]> wrote: > I upped hadoopqa retention to keep last 100 builds and or last 7 days, > whichever comes first. > St.Ack > > On Tue, Nov 4, 2014 at 9:38 AM, Stack <[email protected]> wrote: > >> Branch-1 and master have stabilized and now run mostly blue (give or take >> the odd failure) [1][2]. Having a mostly blue branch-1 has helped us >> identify at least one destabilizing commit in the last few days, maybe two; >> this is as it should be (smile). >> >> Lets keep our builds blue. If you commit a patch, make sure subsequent >> builds stay blue. You can subscribe to [email protected] to get >> notice of failures if not already subscribed. >> >> Thanks, >> St.Ack >> >> 1. https://builds.apache.org/view/H-L/view/HBase/job/HBase-1.0/ >> 2. https://builds.apache.org/view/H-L/view/HBase/job/HBase-TRUNK/ >> >> >> On Mon, Oct 13, 2014 at 4:41 PM, Stack <[email protected]> wrote: >> >>> A few notes on testing. >>> >>> Too long to read, infra is more capable now and after some work, we are >>> seeing branch-1 and trunk mostly running blue. Lets try and keep it this >>> way going forward. >>> >>> Apache Infra has new, more capable hardware. >>> >>> A recent spurt of test fixing combined with more capable hardware seems >>> to have gotten us to a new place; tests are mostly passing now on branch-1 >>> and master. Lets try and keep it this way and start to trust our test runs >>> again. Just a few flakies remain. Lets try and nail them. >>> >>> Our tests now run in parallel with other test suites where previous we >>> ran alone. You can see this sometimes when our zombie detector reports >>> tests from another project altogether as lingerers (To be fixed). Some of >>> our tests are failing because a concurrent hbase run is undoing classes and >>> data from under it. Also, lets fix. >>> >>> Our tests are brittle. It takes 75minutes for them to complete. Many >>> are heavy-duty integration tests starting up multiple clusters and >>> mapreduce all in the one JVM. It is a miracle they pass at all. Usually >>> integration tests have been cast as unit tests because there was no where >>> else for them to get an airing. We have the hbase-it suite now which would >>> be a more apt place but until these are run on a regular basis in public >>> for all to see, the fat integration tests disguised as unit tests will >>> remain. A review of our current unit tests weeding the old cruft and the >>> no longer relevant or duplicates would be a nice undertaking if someone is >>> looking to contribute. >>> >>> Alex Newman has been working on making our tests work up on travis and >>> circle-ci. That'll be sweet when it goes end-to-end. He also added in >>> some "type" categorizations -- client, filter, mapreduce -- alongside our >>> old "sizing" categorizations of small/medium/large. His thinking is that >>> we can run these categorizations in parallel so we could run the total >>> suite in about the time of the longest test, say 20-30minutes? We could >>> even change Apache to run them this way. >>> >>> FYI, >>> St.Ack >>> >>> >>> >>> >>> >>> >>> >> >
