New invocation merge

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

New invocation merge

kkhan
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

jtgreene
Administrator
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.

> On Jan 31, 2017, at 9:03 AM, Kabir Khan <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

jtgreene
Administrator
How about the tests are changed to require a sys prop. That way you don't need a branch.

> On Jan 31, 2017, at 9:07 AM, Jason T. Greene <[hidden email]> 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.
>
>> On Jan 31, 2017, at 9:03 AM, Kabir Khan <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

kkhan
>
> On 31 Jan 2017, at 15:09, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

jtgreene
Administrator
In reply to this post by jtgreene
e.g assumeTrue(toBool(System.getProperty(Xxx)))


> On Jan 31, 2017, at 9:09 AM, Jason T. Greene <[hidden email]> wrote:
>
> How about the tests are changed to require a sys prop. That way you don't need a branch.
>
>> On Jan 31, 2017, at 9:07 AM, Jason T. Greene <[hidden email]> 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.
>>
>>> On Jan 31, 2017, at 9:03 AM, Kabir Khan <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

jtgreene
Administrator
In reply to this post by kkhan
Right exactly.

What does everyone think about a daily or weekly email of the test output to this list?

On Jan 31, 2017, at 9:14 AM, Kabir Khan <[hidden email]> wrote:

>>
>> On 31 Jan 2017, at 15:09, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

kkhan

> On 31 Jan 2017, at 15:16, Jason T. Greene <[hidden email]> wrote:
>
> Right exactly.
>
> What does everyone think about a daily or weekly email of the test output to this list?
Daily would narrow down the range of suspicious commits. Although that information should still be available on TeamCity itself, I think this makes it more visible.

(I take it this is the elaboration about the grouping of the failures? :))

>
> On Jan 31, 2017, at 9:14 AM, Kabir Khan <[hidden email]> wrote:
>
>>>
>>> On 31 Jan 2017, at 15:09, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

jtgreene
Administrator

> On Jan 31, 2017, at 9:20 AM, Kabir Khan <[hidden email]> wrote:
>
>
>> On 31 Jan 2017, at 15:16, Jason T. Greene <[hidden email]> wrote:
>>
>> Right exactly.
>>
>> What does everyone think about a daily or weekly email of the test output to this list?
> Daily would narrow down the range of suspicious commits. Although that information should still be available on TeamCity itself, I think this makes it more visible.
>
> (I take it this is the elaboration about the grouping of the failures? :))

Right I just mean if the goal is to recruit help in resolving test failures, then highlighting it here might be a good way to do that. It might be better than expecting folks to periodically check a special run on team city.

On the other hand it can’t be too noisy, else everyone will just filter it.

This is just an idea, feedback from any and all is welcome.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Martin Choma
In reply to this post by kkhan
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.

On Tue, Jan 31, 2017 at 4:14 PM, Kabir Khan <[hidden email]> wrote:
>
> On 31 Jan 2017, at 15:09, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

kkhan

> On 1 Feb 2017, at 06:42, Martin Choma <[hidden email]> 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 <[hidden email]> wrote:
> >
> > On 31 Jan 2017, at 15:09, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Martin Choma
Right, I see.
You can add property in testsuite/pom.xml to switch InvocationIssue test by default (works for me)

    <properties>
        <excludedGroups>InvocationIssue</excludedGroups>

New CI jobs have to be executed with empty excludedGroups, e.g. -DexcludedGroups=

But I admit SP approach is more obvious here.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Darran Lofthouse
Is there any way we can get this to report when a test that was
potentially excluded actually passed?

I think David has pointed out elsewhere TeamCity is good at showing us
new failures but not new passes.

Regards,
Darran Lofthouse.


On 01/02/17 13:41, Martin Choma wrote:

> Right, I see.
> You can add property in testsuite/pom.xml to switch InvocationIssue test
> by default (works for me)
>
>     <properties>
>         <excludedGroups>InvocationIssue</excludedGroups>
>
> New CI jobs have to be executed with empty excludedGroups, e.g.
> -DexcludedGroups=
>
> But I admit SP approach is more obvious here.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Darran Lofthouse
In reply to this post by Martin Choma
I am going to give @Category a go - with Assume.assumeTrue I think we
have the problem that some tests may be failing in their initialisation
code and that risks leaving behind orphaned processes that break further
tests.

On 01/02/17 13:41, Martin Choma wrote:

> Right, I see.
> You can add property in testsuite/pom.xml to switch InvocationIssue test
> by default (works for me)
>
>     <properties>
>         <excludedGroups>InvocationIssue</excludedGroups>
>
> New CI jobs have to be executed with empty excludedGroups, e.g.
> -DexcludedGroups=
>
> But I admit SP approach is more obvious here.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Darran Lofthouse
That was a short lived decision.

We can only use @Category with the Categories runner but we are already
using the Arquillian runner.

I think back to the system property.

On 02/02/17 18:25, Darran Lofthouse wrote:

> I am going to give @Category a go - with Assume.assumeTrue I think we
> have the problem that some tests may be failing in their initialisation
> code and that risks leaving behind orphaned processes that break further
> tests.
>
> On 01/02/17 13:41, Martin Choma wrote:
>> Right, I see.
>> You can add property in testsuite/pom.xml to switch InvocationIssue test
>> by default (works for me)
>>
>>     <properties>
>>         <excludedGroups>InvocationIssue</excludedGroups>
>>
>> New CI jobs have to be executed with empty excludedGroups, e.g.
>> -DexcludedGroups=
>>
>> But I admit SP approach is more obvious here.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Martin Choma
What do you mean?

@Category is already used in testsuite in conjuction with Arquillian, e.g. WebSecurityBASICTestCase.

On Thu, Feb 2, 2017 at 7:36 PM, Darran Lofthouse <[hidden email]> wrote:
That was a short lived decision.

We can only use @Category with the Categories runner but we are already
using the Arquillian runner.

I think back to the system property.

On 02/02/17 18:25, Darran Lofthouse wrote:
> I am going to give @Category a go - with Assume.assumeTrue I think we
> have the problem that some tests may be failing in their initialisation
> code and that risks leaving behind orphaned processes that break further
> tests.
>
> On 01/02/17 13:41, Martin Choma wrote:
>> Right, I see.
>> You can add property in testsuite/pom.xml to switch InvocationIssue test
>> by default (works for me)
>>
>>     <properties>
>>         <excludedGroups>InvocationIssue</excludedGroups>
>>
>> New CI jobs have to be executed with empty excludedGroups, e.g.
>> -DexcludedGroups=
>>
>> But I admit SP approach is more obvious here.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New invocation merge

Darran Lofthouse
Maybe I misread the doc - it was suggesting to me you needed
@RunWith(Categories)

On 02/02/17 20:49, Martin Choma wrote:

> What do you mean?
>
> @Category is already used in testsuite in conjuction with Arquillian,
> e.g. WebSecurityBASICTestCase.
>
> On Thu, Feb 2, 2017 at 7:36 PM, Darran Lofthouse
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     That was a short lived decision.
>
>     We can only use @Category with the Categories runner but we are already
>     using the Arquillian runner.
>
>     I think back to the system property.
>
>     On 02/02/17 18:25, Darran Lofthouse wrote:
>     > I am going to give @Category a go - with Assume.assumeTrue I think we
>     > have the problem that some tests may be failing in their
>     initialisation
>     > code and that risks leaving behind orphaned processes that break
>     further
>     > tests.
>     >
>     > On 01/02/17 13:41, Martin Choma wrote:
>     >> Right, I see.
>     >> You can add property in testsuite/pom.xml to switch
>     InvocationIssue test
>     >> by default (works for me)
>     >>
>     >>     <properties>
>     >>         <excludedGroups>InvocationIssue</excludedGroups>
>     >>
>     >> New CI jobs have to be executed with empty excludedGroups, e.g.
>     >> -DexcludedGroups=
>     >>
>     >> But I admit SP approach is more obvious here.
>     >>
>     >>
>     >> _______________________________________________
>     >> wildfly-dev mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     >>
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     >
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...