hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Somogyi <psomo...@apache.org>
Subject Re: Flaky test and HBase-adhoc-run-tests job
Date Mon, 02 Sep 2019 08:39:23 GMT

I agree with Nick, feel free to create a feature branch if that makes your
testing easier.

One thing that I'd like to add is if you do not want to have nightly and
flaky test to runs on this branch (probably this is the case for this
specific feature branch) then you should remove the Jenkinsfiles under


I'm not familiar with the job you mentioned so probably you'll need to
keep dev-support/adhoc_run_tests/Jenkinsfile.


On Sat, Aug 31, 2019 at 6:02 PM Nick Dimiduk <ndimiduk@gmail.com> wrote:

> Hi Sakthi,
> I apologize for the delay of reply. I’m not familiar with the details of
> this job, nor am I a recent participant in the community, so I was hoping
> someone with more recent experience would answer these questions.
> To the best of my knowledge, we have no objection to creating jira-specific
> branches in the repo, there are plenty of examples of this in our past.
> Usually they’re done as a means of multi-developer collaboration, but
> that’s not by policy. I think what you propose is a fine use-case for
> pushing a branch. Please observe good hygiene in the shared space and clean
> up after yourself when finished.
> Thanks,
> Nick
> On Thu, Aug 22, 2019 at 14:23 Sakthi <sakthi@apache.org> wrote:
> > Hello,
> >
> > I would like to test the fix to one of the flakies (HBASE-22895). For
> that,
> > I want to utilize our HBase-adhoc-run-tests job to run the test
> repeatedly
> > (~50 times) with the fix and see if it helps before pushing in the fix. I
> > see that currently we only allow any of the branches from the hbase repo
> to
> > be used for the testing in the job.
> >
> > Does that mean that I can create a branch(HBASE-22895) in the repo, push
> > the fix there, run the job & when the issue is rectified, push the fix &
> > delete the branch? Or is creation of new ad_hoc branches in the repo not
> > really necessary or isn't the right way?
> >
> > Would appreciate your suggestions.
> >
> > -Sakthi
> >

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