[
https://issues.apache.org/jira/browse/HBASE-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038135#comment-14038135
]
Andrew Purtell commented on HBASE-11381:
----------------------------------------
Seems a good idea to kick off another build upon failure, with some upper bound
on retries.
The Naginator plugin page says:
{quote}
If the build fails, it will be rescheduled to run again in five minutes. For
each consecutive unsuccessful build, the waiting time is extended by five
minutes. The waiting time is capped at one hour, so after ~12 failing builds in
a row, a new build will only be rescheduled once per hour.
{quote}
We don't want quite that. On private infrastructure a steady stream of nagging
build failure reports are the desired outcome (smile) but ASF Jenkins is a
shared resource.
> Isolate and rerun unit tests that fail following a code commit
> --------------------------------------------------------------
>
> Key: HBASE-11381
> URL: https://issues.apache.org/jira/browse/HBASE-11381
> Project: HBase
> Issue Type: Task
> Reporter: Dima Spivak
>
> It's not uncommon to see that, after changes are committed to a branch, a set
> of unit tests will begin to fail and Hudson will add a comment to the
> relevant JIRAs reporting on the unsuccessful build. Unfortunately, these test
> failures are not always indicative of regressions; sometimes, the problem is
> with infrastructure and simply rerunning the tests can make them go green
> again.
> I propose modifying the Jenkins job that is triggered by a code commit to
> address this problem. In particular, the job could use the reports generated
> by the Maven Surefire plugin to generate a list of tests to rerun. These
> tests can be set to rerun any number of times and a threshold ratio of
> passes-to-fails can be the deciding factor in whether a real bug has been
> introduced following a change in HBase.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
