hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Antonov <olorinb...@gmail.com>
Subject Re: The builds.apache.org grind
Date Fri, 25 Apr 2014 22:51:25 GMT
My 2 cents..

should the test runners have profiles like "ASF build" vs "EC2 large m/c"
or something,
from which the appropriate timeouts are derived, and for ASF timeouts are
longer than for custom envs? Or that would make the whole test infra less
trustworthy?

-Mikhail


2014-04-25 15:47 GMT-07:00 Ted Yu <yuzhihong@gmail.com>:

> Looking at https://builds.apache.org/job/hbase-0.98/ , there were 9 failed
> builds out of the last 17 builds.
> The success rate for
> https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/was even lower.
>
> I think effort of making the builds, especially hbase-0.98, more stable
> should be considered.
>
> My two cents.
>
>
> On Fri, Apr 25, 2014 at 3:13 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > ​​Do we keep filing the "TestFoo occasionally fails on builds.apache.org
> "
> > type of issues as builds.apache.org gets slower and slower? We can see
> the
> > build results independent of JIRA so for documentary purposes the
> rationale
> > seems light.
> >
> > I run the 0.98 unit test suite 20 times daily on JDK 6 and 7 boxes and
> have
> > not observed failures or zombies for a while now. Those EC2 VMs are
> clearly
> > reasonable test environments compared to builds.apache.org, sadly. I'm
> > tempted to close any test issue reporting something on
> > builds.apache.orgthat I don't see as Cannot Reproduce but wonder how
> > common that feeling is.
> >
> > Of course small patches to increase a timeout here or retry more often
> > there could be useful and acceptable. At the same time, do we increase
> the
> > tolerances for builds.apache.org and trade away the effectiveness of the
> > test to catch real timing issues?
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Thanks,
Michael Antonov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message