Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E4B5819D03 for ; Tue, 8 Mar 2016 02:43:38 +0000 (UTC) Received: (qmail 27333 invoked by uid 500); 8 Mar 2016 02:43:38 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 27149 invoked by uid 500); 8 Mar 2016 02:43:38 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 27135 invoked by uid 99); 8 Mar 2016 02:43:37 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Mar 2016 02:43:37 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id A4E86C2AD3 for ; Tue, 8 Mar 2016 02:43:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 5.379 X-Spam-Level: ***** X-Spam-Status: No, score=5.379 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_SBL=4, URIBL_SBL_A=0.1] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudera-com.20150623.gappssmtp.com Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id pAjmyr_vrP41 for ; Tue, 8 Mar 2016 02:43:34 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id C24F35F54F for ; Tue, 8 Mar 2016 02:43:33 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id bc4so2276834lbc.2 for ; Mon, 07 Mar 2016 18:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudera-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IB8aI8JA4U/5x2G9FgbtGuf20RO8oXhY2mfegepoW1g=; b=sZPBxcp7W+2e1RcuNnasrnlacwAL3G8lfdprFFzIAZCDIiPqBp75zDARet/XUfww0L oPO6oam2EQFmVU9cIBKk1Se/ya4aa8bMXeWxmo+9PkvZPPLLH66sTR0BU2QLjcnYCr9K z0rtgFdrOVZ4s9dADxv7GFeO1dlxabM1YuCX5oUg7ypVF1R2/htgBhTiRz81e0/OKHAs A2kJN+Z/a5BJeOoTsDspi3ibWelHWci30NqHb9tjv/UJxv0kQYLCKt/jF2SecloaxvLd OGZynrcmVspgfTYLpfBkBd1vWEJxnmgzZd7djARjval1IweG0mRcV9dPxuVWV/hIEacc 6DHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IB8aI8JA4U/5x2G9FgbtGuf20RO8oXhY2mfegepoW1g=; b=nKGeJ6OVRRf6sMcaUo9gZjcI6a4+f24ZfNctyyWQyrh5QcthQnd+ZfBiJUa1dcUT7P +imUT4P4RX9tFoDkE565SwDeEJXd5bFTWBhujxQRwj1rCoYaWAZyyZCHcqG77294TRtn qoNxEKup8+NCbos6P+CMsSvkaMQ8oBVU0MPKJ1pIdGX722YyV+/5GvU69e9l38ZiWQYf xRc8xDMhBrAXq9aCM0ALTDrMSQl7rskeDBpTuEFIVK0CDFava9TkFNooW+44W/qT0G06 j1KyI7GWhQEu96jNTMF6ZgaE/erykkc4nCLZDNyB38PDPoRCFyuFx/wpK13pupx3rhEw iIhQ== X-Gm-Message-State: AD7BkJJGiFEn1dkcBYvAbwxB8j0B2CSp6TBMX8wqOWlpWJg/SDc6AzGDcexqotPqg3df33oqi7ToJaE4mp8d9grn X-Received: by 10.112.63.200 with SMTP id i8mr8487729lbs.5.1457405013270; Mon, 07 Mar 2016 18:43:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.76.132 with HTTP; Mon, 7 Mar 2016 18:43:13 -0800 (PST) In-Reply-To: References: From: Sean Busbey Date: Mon, 7 Mar 2016 18:43:13 -0800 Message-ID: Subject: Re: Testing and CI -- Apache Jenkins Builds (WAS -> Re: Testing) To: dev Content-Type: multipart/alternative; boundary=001a11c3efde1c419b052d808cd7 --001a11c3efde1c419b052d808cd7 Content-Type: text/plain; charset=UTF-8 I tested things out, and while YETUS-297[1] is present the default runs all plugins that can do multiple jdks against those available (jdk7 and jdk8 in our case). We can configure things to only do a single run of unit tests. They'll be against jdk7, since that is our default jdk. That fine by everyone? It'll save ~1.5 hours on any build that hits hbase-server. On Mon, Mar 7, 2016 at 1:22 PM, Stack wrote: > Hurray! > > It looks like YETUS-96 is in there and we are only running on jdk build > now, the default (but testing compile against both).... Will keep an eye. > > St.Ack > > > On Mon, Mar 7, 2016 at 10:27 AM, Sean Busbey 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 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 > 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 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 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 builds@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 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 --001a11c3efde1c419b052d808cd7--