https://issues.apache.org/jira/browse/YETUS-334
2016-03-15 21:48 GMT+08:00 Sean Busbey <bus...@cloudera.com>: > No, that definitely looks like a bug. Could you please open an issue on the > YETUS jira with a link to the relevant builds and HBASE jiras? > > On Tue, Mar 15, 2016 at 5:44 AM, Phil Yang <ud1...@gmail.com> wrote: > > > Hi all, > > > > Recently pre-commit builds seems run some commands twice. For example, > in > > console of > https://builds.apache.org/job/PreCommit-HBASE-Build/975/console > > or https://builds.apache.org/job/PreCommit-HBASE-Build/978/console , we > > run > > "Patch findbugs detection", "Patch javadoc verification", "Running unit > > tests" twice for each task. HadoopQA also comment repeated results with > > different runtime in JIRA. > > > > We will run tests of hbase-server for four times, twice on jdk7 and twice > > on jdk8, it will be very slow... > > > > Is it as expected? Thanks. > > > > > > 2016-03-15 4:39 GMT+08:00 Stack <st...@duboce.net>: > > > > > https://issues.apache.org/jira/browse/HBASE-15462 > > > > > > Thanks Sean. > > > > > > Looks like a version parse error? > > > > > > St.Ack > > > > > > > > > > > > On Mon, Mar 14, 2016 at 12:55 PM, Sean Busbey <bus...@cloudera.com> > > wrote: > > > > > > > HBASE please, I'll refile to INFRA or wherever if I can figure out > the > > > > source. > > > > > > > > On Mon, Mar 14, 2016 at 12:44 PM, Stack <st...@duboce.net> wrote: > > > > > > > > > On Mon, Mar 14, 2016 at 12:23 PM, Sean Busbey <bus...@cloudera.com > > > > > > wrote: > > > > > > > > > > > is there a jira I can track for the docker failures? > > > > > > > > > > > > > > > > > No. All recent hadoopqas fail. Want an INFRA or HBASE issue? > > > > > Thanks, > > > > > St.Ack > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 14, 2016 at 11:08 AM, Stack <st...@duboce.net> > wrote: > > > > > > > > > > > > > Thanks for making the job configuration all nice and tidy BTW > > Sean. > > > > > > > > > > > > > > I unchecked RUN_IN_DOCKER just now to try and get us over > current > > > > bout > > > > > of > > > > > > > docker build failures. > > > > > > > > > > > > > > St.Ack > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 7, 2016 at 10:27 AM, Sean Busbey < > > bus...@cloudera.com> > > > > > > wrote: > > > > > > > > > > > > > > > FYI, I've just updated our precommit jobs to use the 0.2.0 > > > release > > > > of > > > > > > > Yetus > > > > > > > > that came out today. > > > > > > > > > > > > > > > > After keeping an eye out for strangeness today I'll turn > docker > > > > mode > > > > > > back > > > > > > > > on by default tonight. > > > > > > > > > > > > > > > > On Wed, Jan 13, 2016 at 10:14 AM, Sean Busbey < > > bus...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > FYI, I added a new parameter to the precommit job: > > > > > > > > > > > > > > > > > > * USE_YETUS_PRERELEASE - causes us to use the HEAD of the > > > > > > apache/yetus > > > > > > > > > repo rather than our chosen release > > > > > > > > > > > > > > > > > > It defaults to inactive, but can be used in > > manually-triggered > > > > runs > > > > > > to > > > > > > > > > test a solution to a problem in the yetus library. At the > > > moment, > > > > > I'm > > > > > > > > > using it to test a solution to default module ordering as > > seen > > > > in > > > > > > > > > HBASE-15075. > > > > > > > > > > > > > > > > > > On Fri, Jan 8, 2016 at 7:58 AM, Sean Busbey < > > > bus...@cloudera.com > > > > > > > > > > > > wrote: > > > > > > > > > > FYI, I just pushed HBASE-13525 (switch to Apache Yetus > for > > > > > > precommit > > > > > > > > > tests) > > > > > > > > > > and updated our jenkins precommit build to use it. > > > > > > > > > > > > > > > > > > > > Jenkins job has some explanation: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HBASE-Build/ > > > > > > > > > > > > > > > > > > > > Release note from HBASE-13525 does as well. > > > > > > > > > > > > > > > > > > > > The old job will stick around here for a couple of weeks, > > in > > > > case > > > > > > we > > > > > > > > need > > > > > > > > > > to refer back to it: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HBASE-Build-deprecated/ > > > > > > > > > > > > > > > > > > > > If something looks awry, please drop a note on > HBASE-13525 > > > > while > > > > > it > > > > > > > > > remains > > > > > > > > > > open (and make a new issue after). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 2, 2015 at 3:22 PM, Stack <st...@duboce.net> > > > > wrote: > > > > > > > > > > > > > > > > > > > >> As part of my continuing advocacy of builds.apache.org > > and > > > > that > > > > > > > their > > > > > > > > > >> results are now worthy of our trust and nurture, here > are > > > some > > > > > > > > > highlights > > > > > > > > > >> from the last few days of builds: > > > > > > > > > >> > > > > > > > > > >> + hadoopqa is now finding zombies before the patch is > > > > committed. > > > > > > > > > >> HBASE-14888 showed "-1 core tests. The patch failed > these > > > unit > > > > > > > tests:" > > > > > > > > > but > > > > > > > > > >> didn't have any failed tests listed (I'm trying to see > if > > I > > > > can > > > > > do > > > > > > > > > anything > > > > > > > > > >> about this...). Running our little > > > > > ./dev-tools/findHangingTests.py > > > > > > > > > against > > > > > > > > > >> the consoleText, it showed a hanging test. Running > > locally, > > > I > > > > > see > > > > > > > same > > > > > > > > > >> hang. This is before the patch landed. > > > > > > > > > >> + Our branch runs are now near totally zombie and flakey > > > free > > > > -- > > > > > > > still > > > > > > > > > some > > > > > > > > > >> work to do -- but a recent patch that seemed harmless > was > > > > > causing > > > > > > a > > > > > > > > > >> reliable flake fail in the backport to branch-1* > confirmed > > > by > > > > > > local > > > > > > > > > runs. > > > > > > > > > >> The flakeyness was plain to see up in builds.apache.org > . > > > > > > > > > >> + In the last few days I've committed a patch that > > included > > > > > > javadoc > > > > > > > > > >> warnings even though hadoopqa said the patch introduced > > > > javadoc > > > > > > > issues > > > > > > > > > (I > > > > > > > > > >> missed it). This messed up life for folks subsequently > as > > > > their > > > > > > > > patches > > > > > > > > > now > > > > > > > > > >> reported javadoc issues.... > > > > > > > > > >> > > > > > > > > > >> In short, I suggest that builds.apache.org is worth > > keeping > > > > an > > > > > > eye > > > > > > > > on, > > > > > > > > > >> make > > > > > > > > > >> sure you get a clean build out of hadoopqa before > > committing > > > > > > > anything, > > > > > > > > > and > > > > > > > > > >> lets all work together to try and keep our builds blue: > > > it'll > > > > > save > > > > > > > us > > > > > > > > > all > > > > > > > > > >> work in the long run. > > > > > > > > > >> > > > > > > > > > >> St.Ack > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> On Tue, Nov 4, 2014 at 9:38 AM, Stack <st...@duboce.net > > > > > > 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 > > > > > bui...@hbase.apache.org > > > > > > 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 < > > st...@duboce.net> > > > > > > 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 > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Sean > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > busbey > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > busbey > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > busbey > > > > > > > > > > > > > > > -- > > Thanks, > > Phil Yang > > > > > > -- > busbey > -- Thanks, Phil Yang
