hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Better management of flakies
Date Fri, 01 Apr 2016 20:49:26 GMT
On Fri, Apr 1, 2016 at 10:05 AM, Sean Busbey <busbey@cloudera.com> wrote:
....

> Maybe better if we ensure everything needed to run our jobs is scripts
> in dev-support so that the commiter-only change can just be moving
> jenkins to execute them.
>
>
I like this idea Sean.
St.Ack



> On Fri, Apr 1, 2016 at 12:01 PM, Apekshit Sharma <appy@cloudera.com>
> wrote:
> > So who's setting up the jobs? I don't have perms to do it.
> >
> > On Wed, Mar 30, 2016 at 11:24 AM, Apekshit Sharma <appy@cloudera.com>
> wrote:
> >
> >> So tackling the two parts individually:
> >> 1) Detection : A good automatic flaky detector will no doubt save manual
> >> effort. The one mentioned by Matteo seems like a good one which we can
> hook
> >> up with post-commit job. I see a minor problem though, we'll should use
> >> about 20 runs at least, but the rate of execution of this post-commit
> >> <https://builds.apache.org/view/All/job/HBase-Trunk_matrix/> job for
> >> trunk is too low which means we'll get stale information from the tool.
> One
> >> way around that would be running the post-commit job back-to-back? It
> can
> >> than trigger another job in the end which will use the tool to recompute
> >> flakies.
> >>
> >> 2) Handling: Ignoring flakies in main build and having separate job just
> >> for flakies. We can run it often enough and get some stats on flaky-ness
> >> rate of each test using the same tool as above.
> >>
> >> However, I feel that we should keep it super simple in the start. Just
> >> have a manual list and a separate job for flakies. It it works out
> fine, we
> >> can add the automatic detection and statistics part later.
> >>
> >> - Appy
> >>
> >
> >
> >
> > --
> >
> > Regards
> >
> > Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California |
> > 650-963-6311
>
>
>
> --
> busbey
>

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