[wildfly-dev] New invocation merge

Kabir Khan kabir.khan at jboss.com
Wed Feb 1 05:55:40 EST 2017


> On 1 Feb 2017, at 06:42, Martin Choma <mchoma at redhat.com> wrote:
> 
> Same could be achieved by annotating classes with JUnit @Category(InvocationIssue.class).
> 
> Then you can: 
>     - run only InvocationIssue by specifying -Dgroups=InvocationIssue
>     - run all tests except of InvocationIssue by specifying -DexcludedGroups=InvocationIssue
>     - run all tests by omitting any additional system property
> 
> Advandtage of @Category is you can annotate test method as well.

That does sound nice, but it sounds like omitting the tests becomes opt-in, rather than opt-out. We would have to change all our CI jobs to use -DexcludedGroups=InvocationIssue, apart from the new one we want to create to catch regressions/give up to date progress.

Or is there something which can be configured at pom level to reverse the behaviour?
> 
> On Tue, Jan 31, 2017 at 4:14 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
> >
> > On 31 Jan 2017, at 15:09, Jason T. Greene <jason.greene at redhat.com> wrote:
> >
> > How about the tests are changed to require a sys prop. That way you don't need a branch.
> 
> So rather than @Ignore we add something like
> 
> @BeforeClass
> public static checkRunInvocationTests() {
>         //WFLY-XXXX
>         Assume.assumeTrue(System.getProperty("wildfly.temp.disabled-invocation"))
> }
> 
> >
> >> On Jan 31, 2017, at 9:07 AM, Jason T. Greene <jason.greene at redhat.com> wrote:
> >>
> >> I agree with this approach but we need a way to group these failures in such a way that we know whether or not a change has regressions.
> Can you elaborate a little bit?
> >>
> >>> On Jan 31, 2017, at 9:03 AM, Kabir Khan <kabir.khan at jboss.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> The new invocation library, which is the basis of for the ejb client etc. is currently developed in a branch. There are still about 130-140 test failures, but the team feels it is time to merge to wildfly master at some stage later this week. This will get more visibility of the failures and also lower the barrier of entry for whoever can jump in and help fix the failures.
> >>>
> >>> Are there any objections to merging this?
> >>>
> >>>> From my point of view we would need to @Ignore the failing tests since there are enough transient failures in our testsuite to make it hard to find usual suspects if the number of failed tests is large. We could set up another CI job against a branch which is master with the @Ignores reverted, and I could keep that up to date as I merge to master, so that we get a good picture of the current testsuite failures.
> >>>
> >>> Thanks,
> >>>
> >>> Kabir
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




More information about the wildfly-dev mailing list