FYI, If you submit a pull request and the test fails due to a possible intermittent failure or some environmental problem (github was down or something), instead of rebasing your patch to force a retest, you can now just ask with a phrase that has "retest this please": Could you retest this please? jboss-as-pull-request, you are awesome, now go retest this please! etc

Correct, both the person requesting the test and the PR submitter have to be on it for it to run. Also, if the PR submitter isn't on the whitelist, it will ask one of the admins to confirm. Here is an example: https://github.com/jbossas/jboss-as/pull/2020 On 5/5/12 1:20 AM, Jaikiran Pai wrote: > And I guess, to avoid misuse, only users who are on the whitelist can > trigger that retesting ability? > > -Jaikiran > On Saturday 05 May 2012 11:47 AM, Jason T. Greene wrote: >> FYI, >> >> If you submit a pull request and the test fails due to a possible >> intermittent failure or some environmental problem (github was down or >> something), instead of rebasing your patch to force a retest, you can >> now just ask with a phrase that has "retest this please": >> >> Could you retest this please? >> jboss-as-pull-request, you are awesome, now go retest this please! >> etc >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

It automatically rebases every time it does the testrun. That way if someone submits something on an old tree we get accurate results. Sent from my iPhone On May 6, 2012, at 8:37 PM, Brian Stansberry<brian.stansberry(a)redhat.com> wrote: > Nice! > > However, if things have been committed since you pushed and it's not a > big imposition, it's nice if you rebase to trigger a retest. It's a more > accurate test, and if there are any rebase issues you'll find out early. > > On 5/5/12 1:23 AM, Jason T. Greene wrote: >> Correct, both the person requesting the test and the PR submitter have >> to be on it for it to run. >> >> Also, if the PR submitter isn't on the whitelist, it will ask one of the >> admins to confirm. >> >> Here is an example: >> https://github.com/jbossas/jboss-as/pull/2020 >> >> On 5/5/12 1:20 AM, Jaikiran Pai wrote: >>> And I guess, to avoid misuse, only users who are on the whitelist can >>> trigger that retesting ability? >>> >>> -Jaikiran >>> On Saturday 05 May 2012 11:47 AM, Jason T. Greene wrote: >>>> FYI, >>>> >>>> If you submit a pull request and the test fails due to a possible >>>> intermittent failure or some environmental problem (github was down or >>>> something), instead of rebasing your patch to force a retest, you can >>>> now just ask with a phrase that has "retest this please": >>>> >>>> Could you retest this please? >>>> jboss-as-pull-request, you are awesome, now go retest this please! >>>> etc >>>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 05/07/2012 02:34 AM, Brian Stansberry wrote: > Nice! > > However, if things have been committed since you pushed and it's not a > big imposition, it's nice if you rebase to trigger a retest. It's a more > accurate test, and if there are any rebase issues you'll find out early. Failures are so frequent now that the need for a rebase seems to happen quite rarely for me. One thing that would be nice would be if we could somehow capture which tests regularly fail so those tests can either be fixed or replaced.

On 5/7/12 5:19 AM, Darran Lofthouse wrote: > On 05/07/2012 02:34 AM, Brian Stansberry wrote: >> Nice! >> >> However, if things have been committed since you pushed and it's not a >> big imposition, it's nice if you rebase to trigger a retest. It's a more >> accurate test, and if there are any rebase issues you'll find out early. > > Failures are so frequent now that the need for a rebase seems to happen > quite rarely for me. > > One thing that would be nice would be if we could somehow capture which > tests regularly fail so those tests can either be fixed or replaced. I am tired of them as well. We fixed most of them, but the problem we run into is that some of the intermittent failures are actually critical tests. For example the clustering tests for failover can fail intermittently, but we can't just disable them. For 7.2 I want to eliminate them. I'm thinking maybe we need a new rule, if any test fails intermittently, it will be disabled and the author gets a blocker jira to fix it. What do you guys think, too draconian?

On 5/7/12 9:33 AM, Brian Stansberry wrote: > On 5/7/12 9:25 AM, Jason T. Greene wrote: >> On 5/7/12 5:19 AM, Darran Lofthouse wrote: >>> On 05/07/2012 02:34 AM, Brian Stansberry wrote: >>>> Nice! >>>> >>>> However, if things have been committed since you pushed and it's not a >>>> big imposition, it's nice if you rebase to trigger a retest. It's a >>>> more >>>> accurate test, and if there are any rebase issues you'll find out >>>> early. >>> >>> Failures are so frequent now that the need for a rebase seems to happen >>> quite rarely for me. >>> >>> One thing that would be nice would be if we could somehow capture which >>> tests regularly fail so those tests can either be fixed or replaced. >> >> I am tired of them as well. We fixed most of them, but the problem we >> run into is that some of the intermittent failures are actually critical >> tests. For example the clustering tests for failover can fail >> intermittently, but we can't just disable them. >> >> For 7.2 I want to eliminate them. I'm thinking maybe we need a new rule, >> if any test fails intermittently, it will be disabled and the author >> gets a blocker jira to fix it. What do you guys think, too draconian? >> > > Make it Critical. > > You're always having to fight people who assign "Blocker" to stuff that > wouldn't actually block a release. So better IMHO is to use Critical > unless you feel not getting the test sorted would actually block a > release. Well as an example, can we release with the clustering failover tests disabled? I guess maybe if there is a manual run or something.

On 05/07/2012 04:39 PM, Jason T. Greene wrote: > On 5/7/12 9:33 AM, Brian Stansberry wrote: >> On 5/7/12 9:25 AM, Jason T. Greene wrote: >>> On 5/7/12 5:19 AM, Darran Lofthouse wrote: >>>> On 05/07/2012 02:34 AM, Brian Stansberry wrote: >>>>> Nice! >>>>> >>>>> However, if things have been committed since you pushed and it's >>>>> not a >>>>> big imposition, it's nice if you rebase to trigger a retest. It's >>>>> a more >>>>> accurate test, and if there are any rebase issues you'll find out >>>>> early. >>>> >>>> Failures are so frequent now that the need for a rebase seems to >>>> happen >>>> quite rarely for me. >>>> >>>> One thing that would be nice would be if we could somehow capture >>>> which >>>> tests regularly fail so those tests can either be fixed or replaced. >>> >>> I am tired of them as well. We fixed most of them, but the problem we >>> run into is that some of the intermittent failures are actually >>> critical >>> tests. For example the clustering tests for failover can fail >>> intermittently, but we can't just disable them. >>> >>> For 7.2 I want to eliminate them. I'm thinking maybe we need a new >>> rule, >>> if any test fails intermittently, it will be disabled and the author >>> gets a blocker jira to fix it. What do you guys think, too draconian? >>> >> >> Make it Critical. >> >> You're always having to fight people who assign "Blocker" to stuff that >> wouldn't actually block a release. So better IMHO is to use Critical >> unless you feel not getting the test sorted would actually block a >> release. > > Well as an example, can we release with the clustering failover tests > disabled? I guess maybe if there is a manual run or something. I agree it's a problem. Maybe could we run the default cluster tests on sync replication?

Because these particular ones are all positive tests and I don't remember there would be justification apart from using UDP and ASYNC replication that these tests could fail intermittently. I have seen some test failures in the past were indeed regular failures, its just "luck" that they didn't fail that often... Rado

Correct, both the person requesting the test and the PR submitter have to be on it for it to run. Also, if the PR submitter isn't on the whitelist, it will ask one of the admins to confirm.

On 08/13/2012 03:52 PM, Jeff Mesnil wrote: > On 05/05/2012 08:23 AM, Jason T. Greene wrote: >> Correct, both the person requesting the test and the PR submitter have >> to be on it for it to run. >> >> Also, if the PR submitter isn't on the whitelist, it will ask one of the >> admins to confirm. > > I'm on the whitelist (my PR automatically trigger builds) but I can retest by asking github to retest this please (eg > https://github.com/jbossas/jboss-as/pull/2880#issuecomment-7690581) I can *not* retest jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

It could be the close and re-open that you did that may have stopped it picking it up.

Is this currently disabled? A couple of attempts (one today and one previous week) for this pull request https://github.com/jbossas/jboss-as/pull/2322 didn't trigger any run. -Jaikiran On Saturday 05 May 2012 11:47 AM, Jason T. Greene wrote: > FYI, > > If you submit a pull request and the test fails due to a possible > intermittent failure or some environmental problem (github was down or > something), instead of rebasing your patch to force a retest, you can > now just ask with a phrase that has "retest this please": > > Could you retest this please? > jboss-as-pull-request, you are awesome, now go retest this please! > etc > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev